On 01/20/2014 01:55 AM, Peter Zijlstra wrote:
>
> 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.
The description for commit d331e739f5ad seems to indicate otherwise:
Idle callbacks has some races when enter_idle() sets isidle and
subsequent
interrupts that can happen on that CPU, before CPU goes to idle. Due
to this,
an IDLE_END can get called before IDLE_START. To avoid these races,
disable
interrupts before enter_idle and make sure that all idle routines do not
enable interrupts before entering idle.
This implies to me that once we have set isidle, if we take an interrupt
we *have* to drop out of the idle routine.
> 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.
>
Well, it is obviously needed for the HLT case. For MWAIT it seems like
the MONITOR should have gotten disarmed and therefore MWAIT shouldn't
sleep... I don't know off the top of my head if there are any errata in
that department and/or if there are any other issues.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
