:>     I don't think we want to make sched_lock any more complex then it
:>     already is, so at least for the foreseeable future we are not
:>     going to be able to actually execute an interrupt handler until
:>     the sched_lock is released in (typically) msleep().  I am rather
:Well, my kernel has been executing fast interrupt handlers while sched_lock
:is held for almost a year.  It's actually less complicated with respect to
:sched_lock but more complicated with respect to fast interrupt handlers.
:>     annoyed that two levels of procedure have to be called with the
:>     sched_lock held (mi_switch() and cpu_switch()), leaving interrupts
:>     disabled for a fairly long period of time, but I don't see any way
:>     around it right now.
:The worst offenders for interrupt latency seemed to be calcru() and/or
:the sched_locking related to fork and/or exit.  Latency was many thousand
:instructions (reasonable only on 100+ MIPS machines).  sched_locking for
:calcru() is moostly bogus and should be easy to avoid, but not so for
:context switching.

    Yah, that's a fairly nasty routine.  sched_lock is being used as
    an interlock even more then it is being used to cover scheduler
    queueing operations.  I think the direction I would take would be
    to try to address sched_lock's use rather then try to special case

                                        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