Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

[Mike Galbraith <efault@gmx.de>]

On Fri, 2017-11-24 at 11:26 +0100, Uladzislau Rezki wrote:
> 
> I guess there is misunderstanding here. The main goal is not to cover
> pinned case, for sure. I was thinking more about below points:
> 
> - Extend a claim_wake_up logic for making an ILB/NO_HZ decision more
>   predictable (that is good for mobile workloads). Because as it is
>   right now it simply returns a first CPU in a "nohz" mask and if we
>   know that CPU has been claimed i think it is worth to go with another
>   ILB core, since waking up on a remote CPU + doing nohz_idle_balance
>   does not improve wake-up latency and is a miss from ilb point of view.

Using unsynchronized access of a flag set by chaotic events all over
the box?

> If you have any proposal, i would be appreciated if you could
> share your specific view.

My view is you're barking up the wrong tree: you're making the idle
data SIS is using more accurate, but I question the benefit.  That it
makes an imperfect placement decision occasionally due to raciness is
nearly meaningless compared to the cost of frequent bounce.  Better
(but still not perfect, that requires atomics) state information
doesn't meaningfully improve decision quality.

> Considering a core as not-idle when somebody tends to wake up a task on
> it is a good point. If you have any specific example when it is bad,
> please share it.

I'm not sure how that will work out.  Probably like most everything wrt
SIS, first comes "woohoo" then "aw crap", and off to the trash it goes.

	-Mike