Received: by 10.66.88.200 with SMTP id bi8mr2723644pab.27.1352076904904;
        Sun, 04 Nov 2012 16:55:04 -0800 (PST)
Path: s9ni80613pbb.0!nntp.google.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news-out.octanews.net!indigo.octanews.net!auth.beige.octanews.com.POSTED!not-for-mail
From: Paul Rubin <no.em...@nospam.invalid>
Newsgroups: comp.lang.forth
Subject: Re: [OT] Buddy System Memory Allocator
References: <yZzls.238791$it2.2729@fx22.am4>
Date: Sun, 04 Nov 2012 16:55:01 -0800
Message-ID: <7xvcdkuavu.fsf@ruckus.brouhaha.com>
Organization: Nightsong/Fort GNOX
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:L6PPdHZZFZo3jqMlUf8G0Aopswc=
MIME-Version: 1.0
Lines: 11
NNTP-Posting-Date: 04 Nov 2012 18:55:01 CST
X-Complaints-To: abuse@octanews.net
Bytes: 1363
Content-Type: text/plain; charset=us-ascii

"Mark" <m...@dibsco.co.uk> writes:
> 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 wouldn't worry about this.  You'll lose mucm more memory to the
powers-of-two allocation units if the actual requests will be for blocks
of random size.  You're doing pretty good if your allocator's overhead
is a few percent of the total memory.  In a very small system, the
total number of blocks will be small so the bitmap will be small.  In a
larger system, you can afford a few kilobytes for bitmaps.