:> :(the ICU masks pending interrupts).
:> 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
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
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message