Re: [RFC][PATCH 0/8] sched,idle: need resched polling rework

[Peter Zijlstra <peterz@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]

On Tue, Jun 03, 2014 at 09:52:22AM -0700, Andy Lutomirski wrote:
> > So you could cheat and set it in pick_next_task_idle() and clear in
> > put_prev_task_idle(), that way the entire idle loop, when running has it
> > set.
> >
> 
> Isn't that a little late for sched_ttwu_pending?  I guess it could be
> okay, but I'm hesitant to muck around with the scheduler innards that
> much.  I don't see anything that'll break, though.

Yeah, only later did I see you clear much earlier, which makes sense.

> I'm seriously confused by the polling situation, though.
> TIF_NRFLAG_POLLING is defined for a whole bunch of architectures, but
> I can't find any actual polling idle code outside cpuidle and x86.

I think there's some in ppc somewhere, they poll a bit before doing the
idle hypercall.

> For example, arm defines TIF_POLLING_NRFLAG, but I can't find anything
> that clears the polling bit in the arm code.  Am I missing something
> obvious here? 

It wasn't at all clear to a bunch of arch people wtf that flag was for
and so its got copy/pasted around.

When I recently broke the build with that fetch_or() thing some arch
folks piped up and we ended up removing the flag for arm64 and metag.

Which reminds me, I should probably write a comment somewhere explaining
this stuff.

> Is the whole point of this so that a wakeup that
> happens right after the idle task is scheduled but before it goes idle
> cancels idle and avoids an IPI?  This seems like a lot of complexity
> to avoid IPIs in a hopefully extremely narrow window.
> 
> This is totally backwards for x86, but it seems to do the right thing
> for other architectures.  I'm not convinced it does any good, though.

Its all a bit confused.. back when tglx merged the idle loops we also
flipped the default state around, which didn't improve things.

In any case, I'm only aware of x86 mwait and the ppc amortize poll loop
and the generic poll loop.

That of course doesn't mean there isn't something hidden somewhere in
the 2x archs, but...

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]