: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.

                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

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

Reply via email to