:> :(the ICU masks pending interrupts).
:> :
:> :Bruce
:>     Ok, I have most of it coded up.  Could you explain what 'spending'
:>     was for?
:Like the SWI bits in ipending in RELENG_4.  In RELENG_4, we have to pass
:around all the bits to spl*(), so we had to pack them in at least some
:places (not required in inpending, but efficient).  In -current, packing
:is not so important even if it is possible, so I didn't attempt it.
:>     I am doing it slightly different then you.  To avoid having to use
:>     locked instructions I have placed ipending in the thread structure:
:Mine is global partly for historical reasons.  BTW, I've found that
:variables in the thread struct are more fragile than per-cpu globals.
:You have to remember to deal with them all before you switch threads.
:I needed to clone td_critnest to the next thread in one or two places
:(at least one related to the complications for forking).

    Ah, task switching... that's a stickymess.  In that case, I think placing
    it in a per-cpu variable is the correct solution.  I can still avoid the
    locked bus cycle.

    I dealt with the fork issue by having the trampoline code setup 
    td_critnest before doing to the sti, since it is far too late to
    setup critnest in fork_exit.

:>     OR the irq bit into td->td_ipending (it conveniently already has
:>     the struct thread in %ebx).  And the vector code will also check and
:I do this at the start of sched_ithd().  This is efficient enough because
:the nested case is rare.

    Yup, same here.

:>     handle any non-zero td_ipending if critnest is 0, handling the
:>     1->0 transition/preemption race.
:>     I'll post the patch when it gets a little further along.
:>     How should I deal with fast interrupts?
:Hmm, this gets complicated.  First, you need the td_critnest test
:in Xfastintr* (do it before Xfastintr* calls critical_enter()).  It is
:important in -current (although bad for latency) that critical_enter()
:keeps masking even fast interupts although it doesn't do it in software).
:Next, you need to mask the fast interrupt.  It probably needs to be
:masked in the ICU/APIC on i386's, so it will become not-so-fast.  Finally,
:unpend() needs to do more for fast interrupts:
:- give them highest priority
:- unmask the in the ICU/APIC/wherever, either before or after calling the
:  handler.

    This is fairly straightforward.  I will give the per-cpu area a
    separate pending variable for fast interrupts and maybe a master
    'some kind of interrupt is pending' flag for critical_exit() to

                                        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