linux-kernel - Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

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

Date:   Fri, 24 Nov 2017 19:46:30 +0100
From:   Mike Galbraith <efault@....de>
To:     Uladzislau Rezki <urezki@...il.com>
Cc:     Atish Patra <atish.patra@...cle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Joel Fernandes <joelaf@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Brendan Jackman <brendan.jackman@....com>,
        Josef Bacik <jbacik@...com>, Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race
 window.

On Fri, 2017-11-24 at 11:26 +0100, Uladzislau Rezki wrote:
> 
> I guess there is misunderstanding here. The main goal is not to cover
> pinned case, for sure. I was thinking more about below points:
> 
> - Extend a claim_wake_up logic for making an ILB/NO_HZ decision more
>   predictable (that is good for mobile workloads). Because as it is
>   right now it simply returns a first CPU in a "nohz" mask and if we
>   know that CPU has been claimed i think it is worth to go with another
>   ILB core, since waking up on a remote CPU + doing nohz_idle_balance
>   does not improve wake-up latency and is a miss from ilb point of view.

Using unsynchronized access of a flag set by chaotic events all over
the box?

> If you have any proposal, i would be appreciated if you could
> share your specific view.

My view is you're barking up the wrong tree: you're making the idle
data SIS is using more accurate, but I question the benefit.  That it
makes an imperfect placement decision occasionally due to raciness is
nearly meaningless compared to the cost of frequent bounce.  Better
(but still not perfect, that requires atomics) state information
doesn't meaningfully improve decision quality.

> Considering a core as not-idle when somebody tends to wake up a task on
> it is a good point. If you have any specific example when it is bad,
> please share it.

I'm not sure how that will work out.  Probably like most everything wrt
SIS, first comes "woohoo" then "aw crap", and off to the trash it goes.

	-Mike