Message from discussion Buddy System Memory Allocator
Received: by 10.180.82.193 with SMTP id k1mr785301wiy.0.1350664666789;
Fri, 19 Oct 2012 09:37:46 -0700 (PDT)
From: Pascal J. Bourguignon <p...@informatimago.com>
Subject: Re: Buddy System Memory Allocator
Date: 19 Oct 2012 16:37:45 GMT
References: <email@example.com> <firstname.lastname@example.org>
X-Trace: individual.net Ej+/vxrfJkuTZWQYyJ+HYQkhc9mJTR90iVBhUKQgneAxuy5HjFtj+cInPp2G+8fyCE
User-Agent: NewsTap/3.5.5 (iPad)
Content-Type: text/plain; charset=UTF-8
"BartC" <b...@freeuk.com> wrote:
> "Pascal J. Bourguignon" <p...@informatimago.com> wrote in message
>> "Mark" <m...@dibsco.co.uk> wrote:
>>> of memory and want a relatively small minimum block size. A bitmap of 32
>>> bits will only give me coverage for 8k of memory if I use a minimum block
>>> size of 256 bytes. I am trying to figure out how to avoid having a bitmap
>>> that is hundreds or thousands of bits long. I'm sure that there must be a >> better way.
>> The simpliest is to keep the size with the allocated blocks: allocate a
>> word more than requested, to store the size, and return the addess of the
>> first byte after the size. You may want to still return aligned pointers
>> so you may want to store the size on a smaller alignment.
> He's complaining about having to use a 4 byte bitmap for every 8KB (1 bit per 256 bytes).
> Your way might need 4 bytes for every 256 bytes! And could introduce
> alignment issues (260 bytes per block also sound as a bit awkward).
You cut it too soon. My proposition has two limbs: use a size prefix for
big blocks, and use blocks of fixed small size allocated from common fixed
size block pools (superblocks).
__Pascal J. Bourguignon__