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" frees. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
