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
handler.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
