Re: wake_wide mechanism clarification

[Joel Fernandes]

On Sat, Jul 29, 2017 at 3:28 PM, Joel Fernandes <joelaf@xxxxxxxxxx> wrote:
<snip>
>>>> Again I didn't follow why the second condition couldn't just be:
>>>> waker->nr_wakee_switch > factor, or, (waker->nr_wakee_switch +
>>>> wakee->nr_wakee_switch) > factor, based on the above explanation from
>>>> Micheal Wang that I quoted.
>>>> and why he's instead doing the whole multiplication thing there that I
>>>> was talking about earlier: "factor * wakee->nr_wakee_switch".
>>>>
>>>> Rephrasing my question in another way, why are we talking the ratio of
>>>> master/slave instead of the sum when comparing if its > factor? I am
>>>> surely missing something here.
>>>
>>> Because the heuristic tries to not demolish 1:1 buddies.  Big partner
>>> flip delta means the pair are unlikely to be a communicating pair,
>>> perhaps at high frequency where misses hurt like hell.
>>
>> But it does seem to me to demolish the N:N communicating pairs from a
>> latency/load balancing standpoint. For he case of N readers and N
>> writers, the ratio (master/slave) comes down to 1:1 and we wake
>> affine. Hopefully I didn't miss something too obvious about that.
>
> I think wake_affine() should correctly handle the case (of
> overloading) I bring up here where wake_wide() is too conservative and
> does affine a lot, (I don't have any data for this though, this just
> from code reading), so I take this comment back for this reason.

aargh, nope :( it still runs select_idle_sibling although on the
previous CPU even if want_affine is 0 (and doesn't do the wider
wakeup..), so the comment still applies.. its easy to get lost into
the code with so many if statements :-\  sorry about the noise :)

thanks,

-Joel