Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ciYwN-0005Lj-Td for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Feb 2017 03:59:08 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1ciYwN-0004A5-Do for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Feb 2017 03:59:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ciYut-0001H6-3A for pgsql-hackers@postgresql.org; Tue, 28 Feb 2017 03:57:35 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ciYuq-0000wg-Ct for pgsql-hackers@postgresql.org; Tue, 28 Feb 2017 03:57:34 +0000 Received: from pro.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v1S3vQ9c016279; Mon, 27 Feb 2017 22:57:26 -0500 From: Tom Lane To: Andres Freund cc: Tomas Vondra , Petr Jelinek , Petr Jelinek , Robert Haas , John Gorman , pgsql-hackers Subject: Re: PATCH: two slab-like memory allocators In-reply-to: <20170228034232.4h7ouyhxq4lbbao2@alap3.anarazel.de> References: <20170224221038.43xf2cyonczzr6hb@alap3.anarazel.de> <20170227111732.vrx5v72ighehwpkf@alap3.anarazel.de> <20170227120200.5jc3ubg5jrqaznd7@alap3.anarazel.de> <26061.1488209545@sss.pgh.pa.us> <20170227155532.o7casczq5parlmz4@alap3.anarazel.de> <20170227164828.akgzeg6ggl2v4x7s@alap3.anarazel.de> <12622.1488216468@sss.pgh.pa.us> <20170227174201.yrofai7neyp6shb2@alap3.anarazel.de> <20170228034232.4h7ouyhxq4lbbao2@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Mon, 27 Feb 2017 19:42:32 -0800" Date: Mon, 27 Feb 2017 22:57:24 -0500 Message-ID: <1240.1488254244@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Andres Freund writes: > Independently of this, we really should redefine StandardChunkHeader to > be only the MemoryContext. There's no need to have size/requested_size > part of StandardChunkHeader, given there's > MemoryContextMethods->get_chunk_space(). Yeah, perhaps. The trick would be to get things laid out so that the MemoryContext pointer is always immediately adjacent to the chunk data (no padding between). One could imagine redefining aset.c's chunk header along the lines of typedef struct AllocSetChunkHeader { Size size; /* size of data space allocated in chunk */ #ifdef MEMORY_CONTEXT_CHECKING Size requested_size; /* original request size */ #if 32-bit-but-maxalign-is-8 Size padding; /* needed to avoid padding below */ #endif #endif MemoryContext context; /* owning context */ /* there must not be any padding to reach a MAXALIGN boundary here! */ } AllocSetChunkHeader; where we'd possibly need some help from configure to implement that inner #if condition, but it seems doable enough. If the slab allocator would be happier with just a MemoryContext pointer as chunk header, I think we should push in this direction rather than invent some short-term hack. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers