linux-kernel - Re: wake_wide mechanism clarification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170731122149.GA7539@li70-116.members.linode.com>
Date:   Mon, 31 Jul 2017 12:21:50 +0000
From:   Josef Bacik <josef@...icpanda.com>
To:     Joel Fernandes <joelaf@...gle.com>
Cc:     Mike Galbraith <umgwanakikbuti@...il.com>,
        Josef Bacik <josef@...icpanda.com>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Juri Lelli <Juri.Lelli@....com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Patrick Bellasi <patrick.bellasi@....com>,
        Brendan Jackman <brendan.jackman@....com>,
        Chris Redpath <Chris.Redpath@....com>,
        Michael Wang <wangyun@...ux.vnet.ibm.com>,
        Matt Fleming <matt@...eblueprint.co.uk>
Subject: Re: wake_wide mechanism clarification

On Sat, Jul 29, 2017 at 03:41:56PM -0700, Joel Fernandes wrote:
> On Sat, Jul 29, 2017 at 3:28 PM, Joel Fernandes <joelaf@...gle.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 :)
> 

I've been working in this area recently because of a cpu imbalance problem.
Wake_wide() definitely makes it so we're waking affine way too often, but I
think messing with wake_waide to solve that problem is the wrong solution.  This
is just a heuristic to see if we should wake affine, the simpler the better.  I
solved the problem of waking affine too often like this

https://marc.info/?l=linux-kernel&m=150003849602535&w=2

So why do you care about wake_wide() anyway?  Are you observing some problem
that you suspect is affected by the affine wakeup stuff?  Or are you just trying
to understand what is going on for fun?  Cause if you are just doing this for
fun you are a very strange person, thanks,

Josef