On Sun, 24 Feb 2002, Matthew Dillon wrote:

> :cpu_switch() certainly needs to do this if it can be called with the
> :interrupt enable flag[s] in different states.  I need the sti's (actually
> :enable_intr()'s because I don't want fast interrupts to be disabled
> :during context switches.  This works because enabling interrupts is sure
> :to be safe, since we might be switching to a thread that will enable
> :them.  Some sort of lock is needed to prevent interrupts interfering
> :with the switch.  I think soft-masking them in critical_enter() is
> :sufficient in your version too.
>     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.

>     Eventually (presumably) we will have per-cpu run queues.  That combined
>     with interrupt stealing may resolve the problem for us.   I am still
>     not convinced that making the various *pending* flags globals will
>     be more efficient, because it introduces significant cache mastership
>     issues.  It might be easier to do this:

OK.  I don't care about this yet.


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

Reply via email to