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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 18 Aug 2017 14:34:55 +0900
From:   Byungchul Park <byungchul.park@....com>
To:     "Joel Fernandes (Google)" <joel.opensrc@...il.com>
Cc:     Peter Zijlstra <peterz@...radead.org>, mingo@...nel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        juri.lelli@...il.com, rostedt@...dmis.org, kernel-team@....com
Subject: Re: [PATCH v6 0/2] Make find_later_rq() choose a closer cpu in
 topology

On Thu, Aug 17, 2017 at 09:51:34PM -0700, Joel Fernandes (Google) wrote:
> On Thu, Aug 17, 2017 at 6:25 PM, Byungchul Park <byungchul.park@....com> wrote:
> > On Mon, Aug 07, 2017 at 12:50:32PM +0900, Byungchul Park wrote:
> >> When cpudl_find() returns any among free_cpus, the cpu might not be
> >> closer than others, considering sched domain. For example:
> >>
> >>    this_cpu: 15
> >>    free_cpus: 0, 1,..., 14 (== later_mask)
> >>    best_cpu: 0
> >>
> >>    topology:
> >>
> >>    0 --+
> >>        +--+
> >>    1 --+  |
> >>           +-- ... --+
> >>    2 --+  |         |
> >>        +--+         |
> >>    3 --+            |
> >>
> >>    ...             ...
> >>
> >>    12 --+           |
> >>         +--+        |
> >>    13 --+  |        |
> >>            +-- ... -+
> >>    14 --+  |
> >>         +--+
> >>    15 --+
> >>
> >> In this case, it would be best to select 14 since it's a free cpu and
> >> closest to 15(this_cpu). However, currently the code select 0(best_cpu)
> >> even though that's just any among free_cpus. Fix it.
> >
> > Could you let me know your opinions about this?
> 
> Patch looks good to me, I would also add a comment ontop of
> fallback_cpu (I think Steve mentioned similar thing at [1])
> 
> /*
>  * fallback is the closest CPU in the closest SD incase
>  * all domains are PREFER_SIBLING
>  */
>  if (fallback_cpu == -1)
>      fallback_cpu = best_cpu;
> 
> And clarify this in the commit message.

Right. I will add it.

Thank you very much,
Byungchul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ