On Sat, Feb 23, 2002 at 03:12:36PM -0800, Matthew Dillon wrote:
> :OTOH, A per CPU bucket list means no bucket mtx would be necessary;
> :without that, it's just replacing one type of contention for another,
> :I think, until you start making mutex selection indeterminate. 8^(.
> :Really, this delayed freeing idea is starting to get uglier than
> :just going to per CPU pools...
> :-- Terry
> Well, if we want to rewrite malloc() a per-cpu pool inside a critical
> section would not be that difficult. The 'bucket' array would
> simply be placed in the per-cpu area. However, with malloc() we still
> have a serious problem with the malloc_type structure statistics. There
> would have to be per-cpu information for those as well.
Someone (jeffr) is already working on a new allocator to hopefully
[at least] eventually replace malloc(9) and various other kernel
allocators. It will support per CPU working-sets and some cache friendly
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message