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:   Thu, 23 Nov 2017 14:13:01 +0100
From:   Mike Galbraith <efault@....de>
To:     Uladzislau Rezki <urezki@...il.com>,
        Atish Patra <atish.patra@...cle.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     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 Thu, 2017-11-23 at 11:52 +0100, Uladzislau Rezki wrote:
> Hello, Atish, Peter, all.
> 
> I have a question about if a task's nr_cpus_allowed is 1.
> In that scenario we do not call select_task_rq. Therefore
> even thought a task "p" is placed on idle CPU that CPU
> will not be marked as claimed for wake-up.
> 
> What do you think about adding per_cpu(claim_wakeup, cpu) = 1;
> to select_task_rq() instead and possibly get rid of them from
> other places (increases a race window a bit)?

My thoughts on all of this is that we need less SIS, not more.  Rather
than trying so hard for the absolute lowest wakeup latency, which
induces throughput/efficiency robbing bouncing, I think we'd be better
of considering leaving an already llc affine task where it is if the
average cycle time is sufficiently low that it will likely hit the CPU
RSN.  Completely ignoring low utilization kernel threads would go a
long way to getting rid of bouncing userspace (which tends to have a
meaningful footprint), all over hell and creation.

You could also periodically send mobile kthreads down the slow path to
try to keep them the hell away from partially busy CPUs, as well as
anything else that hasn't run for a while, to keep background cruft
from continually injecting itself into the middle of a cross core
cyber-sex.

	-Mike