: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.
critical_enter() isn't much better then a mutex. It can
be optimized to get rid of the inline cli & sti however. Actually, it
can be optimized trivially for i386, all we have to do is check the
critical nesting count from the interrupt code and set the
interrupts-disabled bit in the returned (supervisor mode) frame.
critical_enter() and critical_exit() would then be nearly perfect.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
