Re: libhurd-cap-server/class-alloc.c

[Marcus Brinkmann]

At Mon, 17 Jan 2005 11:01:53 +0000,
Neal H. Walfield wrote:
>  - only reap on a per-slab basis shifting the burden to the pager

How will the pager do the locking/reaping?  If we don't have an
internal lock, it needs to use some hook provided by the user.  And
how will the pager learn about the slab?

Or are you saying that slabs are not automatically reaped anymore,
shifting the responsibility to not only pager, but to the user of the
slab?

> Finally, it is worth adding that caching buffers for non-wired spaces
> may negatively impact performance: if the buffer is paged out and
> eventually reused, the page-in operation may be more expensive than
> just initializing some fresh memory.

Good point.

I think we need a way to prevent dropping buffers, though (essentially
your wired option, I guess, although it doesn't specifically require
that).  The specific application I am thinking about is task, and that
is always wired, so it is a simple case really.  The reason is that I
wanted to allocate thread numbers when creating the slab cache object,
and then use the slab cache also as a way to find free thread numbers
at thread allocation.  Thinking about it, this may not be the best
thing to do, so maybe I should just drop that and manage thread
numbers differently.

>  - have callers invoke the reap function on specific slabs
>  - require callers to serialize access to slabs
>  - modify hurd_slab create to take an additional attribute which
>    indicates whether unused buffers should be cached or just
>    immediately deallocated

Sounds good to me.

Thanks,
Marcus