Re: slab allocator

[Johan Rydberg]

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