[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: slab allocator
From: |
Johan Rydberg |
Subject: |
Re: slab allocator |
Date: |
Thu, 18 Sep 2003 12:58:58 +0200 |
Marcus Brinkmann <address@hidden> wrote:
: This looks very great already. I have not digged through it completely
: (yet), but what I saw was good. We will need assignment papers for you (you
: know the drill), and I can put it in when the process is under way.
Good.
: [removed snippet about my bad english]
: As for releasing memory, it might be a good idea to have a function that
: can be called on page pressure to release a specified number of pages
: (if possible).
That shouldn't be a problem. All that has to be done is to scan through
the slab list and release all slabs that has a reference counter of zero.
The only thing really is that there has to be a list of all created
slab spaces (so the reaper can find the slab lists.)
: However, that is just a guess by me, and we can wait until we know more
: about how paging works until we decide how to do it. What do others do?
The normal thing is that when the VM-system needs more memory, it calls
a reaper function which returns memory (if it can.)
As you can see in hurd_slab_dealloc, first_free always points to the slab
with the greatest number of free object. I have a feeling that this may
cause a lot of half-empty slabs -> the normal fragmentation problems in
the sence that it will be hard to return memory to the system, But as I
said, it's just a feeling. I will have to research this more.
Now I have to get back to my hangover.
--
Johan Rydberg, Free Software Developer, Sweden
http://rtmk.sf.net | http://www.nongnu.org/guss/
Playing Plump DJs v.s. LFO - Low Frequency Bootilator