On Sat, Jul 29, 2017 at 3:28 PM, Joel Fernandes <joe...@google.com> 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
