All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: uClinux development list <uclinux-dev@uclinux.org>
Cc: linux-kernel@vger.kernel.org, rgetz@blackfin.uclinux.org
Subject: Re: RFC: Non Power of 2 memory allocator
Date: 25 Mar 2006 17:21:30 +0100	[thread overview]
Message-ID: <p73mzfepkad.fsf@verdi.suse.de> (raw)
In-Reply-To: <6.1.1.1.0.20060325090152.01ec63f0@ptg1.spd.analog.com>

Robin Getz <rgetz@blackfin.uclinux.org> writes:

> The  buddy system allocates things in power of 2 pages sizes (4k, 8k,
> 16k, 32k, 64k, 128k, 256k, 512k, 1024k), which works fine on most
> systems, but an embedded system, which is running without a MMU (
> Memory Management Unit) - RAM is precious, and when you only need
> 129k for an application, you don't want to allocate a power of 2,
> which gives you 256k -  an extra 127k, which can't be used by
> anything else.

In 2.4 I solved this problem at some point by just returning
the excess pages to the buddy allocator. There was even
a nice function to do this (alloc_exact)

That won't work for slab, but does for __get_free_pages() which
is better for large allocations anyways. slab imho doesn't make
sense for allocation anywhere bigger PAGE_SIZE/2. At some
point in 2.6 there was trouble with "compound pages" but I think
that has been resolved. 

Just implementing alloc_exact again would be the simplest solution
for your problem.

-Andi

       reply	other threads:[~2006-03-25 16:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <6.1.1.1.0.20060325090152.01ec63f0@ptg1.spd.analog.com>
2006-03-25 16:21 ` Andi Kleen [this message]
2006-03-25 17:51   ` RFC: Non Power of 2 memory allocator Hugh Dickins
2006-03-26  0:32     ` Nick Piggin
     [not found] <mailman.10486.1143303698.3925.uclinux-dev@uclinux.org>
2006-03-25 16:58 ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=p73mzfepkad.fsf@verdi.suse.de \
    --to=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgetz@blackfin.uclinux.org \
    --cc=uclinux-dev@uclinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.