Re: RCU question

From: George Anzinger
Date: Sun Dec 12 2004 - 11:53:17 EST


Manfred Spraul wrote:
Andrea Arcangeli wrote:

On Sun, Dec 12, 2004 at 09:59:00AM +0100, Manfred Spraul wrote:


It means that our NMI irq return path should check if it points to a hlt instruction and if yes, then increase the saved EIP by one before doing the iretd, right?


I don't think we'll ever post any event through nmi, so it doesn't
matter. We only care to be waken by real irqs, not nmi/smi. Idle loop is
fine to ignore the actions of the nmi handlers and to hang into the
"hlt".


No, You misunderstood the problem:

sti
** NMI handler
** normal interrupt arrives, is queued by the cpu
** irqd from NMI handler
** cpu notices the normal interrupt, handles it.
** normal interrupt does a wakeup, schedules a tasklet, whatever

I think you are forgetting that the system does the full context switch from the interrupt handler (well, actually from entry.S) and does not do the irqd until it is time to go back to the idle thread (i.e. there is nothing left to do), so..
** irqd from normal interupt
hlt << cpu sleeps.

What we loose here is that idle does not go around its little loop again. If an interrupt becomes pending on the way to the hlt, i.e. while entry.S has interrupts masked and is doing the irqd, it will be handled prior to the hlt so we could loose several of these idle loop spins, until no interrupt is pending allowing the hlt to be executed. On the next interrupt/irqd the hlt will exit. So what is lost is one or more spins round the idle loop.

The "normal" idle loop just looks at the need_resched flag and goes right back to the hlt, however, idle, it self, never sets this flag, only interrupt code can set it at this point, and the interrupt exit takes action to clear it so I don't see it every being found set in the idle loop (I suppose one could do a test to see if it is ever found set here), so, in theory, the net effect should be nill.

Did I miss something?

--
George Anzinger george@xxxxxxxxxx
High-res-timers: http://sourceforge.net/projects/high-res-timers/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/