linux-kernel - 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-next>] [day] [month] [year] [list]

Date:   Thu, 29 Jun 2017 17:19:14 -0700
From:   Joel Fernandes <joelaf@...gle.com>
To:     Mike Galbraith <umgwanakikbuti@...il.com>
Cc:     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>,
        Josef Bacik <jbacik@...com>
Subject: wake_wide mechanism clarification

Dear Mike,

I wanted your kind help to understand your patch "sched: beef up
wake_wide()"[1] which is a modification to the original patch from
Michael Wang [2].

In particular, I didn't following the following comment:
" to shared cache, we look for a minimum 'flip' frequency of llc_size
in one partner, and a factor of lls_size higher frequency in the
other."

Why are wanting the master's flip frequency to be higher than the
slaves by the factor?

The code here is written as:

if (slave < factor || master < slave * factor)
   return 0;

However I think we should just do (with my current and probably wrong
understanding):

if (slave < factor || master < factor)
    return 0;

Basically, I didn't follow why we multiply the slave's flips with
llc_size. That makes it sound like the master has to have way more
flips than the slave to return 0 from wake_wide. Could you maybe give
an example to clarify? Thanks a lot for your help,

I am also CC'ing Peter and some ARM folks for the discussion (and also
Jocef who was discuss it with Mike on the mailing list few years ago).

Thanks,
Joel

[1] https://patchwork.kernel.org/patch/6787941/
[2] https://lkml.org/lkml/2013/7/4/20