Alfred Perlstein wrote:
> All these per-subsystem free-lists are making me nervous in both
> complexity and wasted code...

Me too.

> Ok, instead of keeping all these per-subsystem free-lists here's what
> we do:
> In kern_malloc:free() right at the point of
>   if (size > MAXALLOCSAVE) we check if we have Giant or not.
>     if we do not then we simply queue the memory
>     however, if we do then we call into kmem_free with all the queued memory.
> This ought to solve the issue without making us keep all these
> per-cpu caches.

One modification: limit the number that are freed per invocation
to some number small enough that there won't be a big latency.

Once everything gets to this point, though, there will be nothing
to trigger a free with giant held, and you'll just queue things
up forever.

Really, we need counted queues -- queues that know the number of
elemenets on them.  This is a requirement for RED-Queueing, and
it will let us know when the queue gets deep... then you can grab
giant, and flush down the queue if it hits a high watermark.

Obviously, the correct way to handle this is per CPU memory pools
that don't have any need for lock contention at all on the "real"

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to