Re: RCU question

[George Anzinger <george@mvista.com>]

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@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/