Re: linux-next: build failure after merge of the tip tree

[Peter Zijlstra]

On Mon, Jan 20, 2014 at 01:23:00AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
> >>
> >> The difference is the STI!
> > 
> > So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
> > 
> 
> No, that doesn't work.  The point of __sti_mwait() is that the STI is
> the instruction immediately before the MWAIT, just like the combination
> STI;HLT.  Since the execution of STI is always delayed by one
> instruction, these two instructions form an atomic unit, which means
> interrupts are enabled "after" we have entered MWAIT or HLT.
> 
> > But that's entirely different from saying that core2 doesn't support
> > mwait_idle_with_hints because its a different instruction.
> 
> If you think of STI;MWAIT as a "compound instruction" it kind of is.
> Newer CPUs don't have to play that trick anymore, because there is a
> flag to MWAIT which breaks us out of MWAIT on a pending interrupt
> without having to actually enable interrupts at the point of the MWAIT.

Ok, so I still don't get the problem of enabling interrupts early.

If we enable them early we can get interrupts; which afaict fall into
two groups, those that do and do not set NEED_RESCHED.

For those that do not set NEED_RESCHED, we'd have woken from MWAIT/HLT
and looped right back into it, so receiving those early -- before
actually calling MWAIT/HLT seems like a NO-OP.

For those setting NEED_RESCHED, we test NEED_RESCHED in all the right
places.

 - current_set_polling_and_test(), we test need_resched after telling
   remote CPUs they don't need to send interrupts because we're polling
   for it -- the remote cpus set NEED_RESCHED before testing if we're
   polling for it.

 - we test NEED_RESCHED after setting up the monitor and before calling
   MWAIT. Therefore, if an interrupt would happen right before we call
   MWAIT, the monitor is already set and the MWAIT does an immediate
   exit.

AFAICT we simply cannot get stuck and miss a NEED_RESCHED this way.



--
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/