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

Bosko Milekic

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

Reply via email to