Date: Sat, 18 Feb 2006 10:32:11 -0800 From: Jason Evans <jasone@FreeBSD.org> To: Brian Candler <B.Candler@pobox.com> Cc: freebsd-current@freebsd.org Subject: Re: Virtual memory consumption (both user and kernel) in modern CURRENT Message-ID: <43F7682B.7050604@FreeBSD.org> In-Reply-To: <20060218083837.GB42791@uk.tiscali.com> References: <20060215024339.N22450@atlantis.atlantis.dp.ua> <43F29BF5.4060300@freebsd.org> <20060216140725.T23429@atlantis.atlantis.dp.ua> <20060217013427.GB31540@xor.obsecurity.org> <20060217093631.J79078@atlantis.atlantis.dp.ua> <43F5F9BB.6000607@FreeBSD.org> <20060218083837.GB42791@uk.tiscali.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Brian Candler wrote: > Would it be possible to have some sort of "slow start" algorithm? For > example, first block allocated is 1MB, next block allocated is 4MB, > subsequent blocks are 16MB? > > I don't know anything about the internal data structures of jemalloc, but if > you treat "4MB" as 4 x 1MB and "16MB" as 16 x 1MB, then you'd have > effectively a pool of 1MB blocks, but apart from the first few, they'd be > allocated contiguously. Each chunk is aligned at an address that is a multiple of the chunk size. This makes it possible to use bitmasking to find the beginning of the containing chunk for any allocation in constant time, with no locking. This is critical to the correct, scalable functioning of the allocator. It would be possible to create chunks that are smaller than the standard chunk size, but they would still have to be aligned at multiples of the standard chunk size. This would leave trailing space that wouldn't be useful to the allocator. It would in some cases be possible to extend small chunks to the standard size, but this would cause some bad interactions with the layout policy (large objects are usually carved from the end of the chunk). As such, creating smaller chunks doesn't fit very well with the allocator design. Thanks, Jason
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43F7682B.7050604>