On Sat, 23 Feb 2002, Matthew Dillon wrote:

> :ipending here works much as in RELENG_4.  It is ORed into by sched_ithd()
> :if curthread->td_critnest != 0.  Nothing special is needed for pci
> :(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).

> void
> critical_enter(void)
> {
>         struct thread *td = curthread;
>         ++td->td_critnest;
> }
> void
> critical_exit(void)
> {
>         struct thread *td = curthread;
>         KASSERT(td->td_critnest > 0, ("bad td_critnest value!"));
>         if (--td->td_critnest == 0) {
>                 if (td->td_ipending)
>                         unpend();
>         }
> }
>     The apic and icu vector code will do a simple td_critnest test and
>     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.

>     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


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

Reply via email to