On Sun, 24 Feb 2002, Matthew Dillon wrote:

>     Bruce, your sys.dif was *invaluable*!  It would have taken me a lot
>     longer to figure out the interrupt disablement requirement around
>     the icu_lock, and the statclock and hardclock forwarding issues (which I
>     got working by the way!).


>     It turns out that putting the pending masks in the per-cpu area was
>     the right solution!  It made statclock and hardclock forwarding easy
>     (I can see why you didn't even try in your patch set, doing it with
>     a global mask would be nearly impossible).  In fact, it made everything
>     unbelievably easy.

>     ...

      [This paragraph reordered]
>     up.  One of the best things about this patch set is that it is really
>     flexible.  We should be able to really make interrupts fly.  In fact,
>     it should even be possible for one cpu to steal another cpu's pending
>     interrupt(s) fairly trivially, without having to resort to IPIs.

Good idea.  Stealing would be even easier if the mask were global :-).

>     The second issue is that cpu_switch() does not save/restore the
>     PSL_I (interrupt disablement mask).  I added a PSL word to the PCB
>     structure to take care of the problem.  Without this if you have
>     a thread switch away while holding interrupts hard-disabled, the
>     next thread will inherit the hard disablement.  I saw the sti's
>     you added in various places but I figured the best solution was
>     to simply save/restore the state.  The original code didn't have

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.


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

Reply via email to