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