linux-kernel - Re: Scheduler wakeup path tuning surface: Interface discussion

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]

Message-ID: <5a1b78c0-f286-bfaf-55bf-132093801131@linux.ibm.com>
Date:   Thu, 12 Nov 2020 11:43:46 +0530
From:   Parth Shah <parth@...ux.ibm.com>
To:     Patrick Bellasi <patrick.bellasi@...bug.net>,
        Dhaval Giani <dhaval.giani@...cle.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Josef Bacik <jbacik@...com>,
        Chris Hyser <chris.hyser@...cle.com>, riel@...riel.com
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Paul Turner <pjt@...gle.com>, Ben Segall <bsegall@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jonathan Corbet <corbet@....net>
Subject: Re: Scheduler wakeup path tuning surface: Interface discussion

I was analyzing LPC 2020 discussion regarding Latency-nice interface and
have below points to initiate further discussion:

1. There was consensus that having interface like "Latency-nice" to
provide scheduler hints about task latency requirement can be very useful.

2. There are two use-case regarding the change in the number of CPUs to
be searched in select_idle_cpu path:
- milli-seconds optimization: Perform more scans to find idle CPUs to
reduce latency in milliseconds
- micro-seconds optimization: Perform less searches and queue it to any
CPU when system is overloaded

Both these optimization are contradictory since one requires to reduce
search space for latency sensitive task while other wants to increase
it. Though we can think about tuning select_idle_cpu path by keeping
mask of idle CPUs or applying other tricks, it will always be a
trade-off to search more or less and that's where latency-nice like
attribute can be useful for task aware decisions.

3. Using range is non-deterministic, meaning it is difficult to classify
a task should be marked with value of -18 or -19 and there will be
non-deterministic impact on system performance between these values.

And that's where should we even think of using "Flags" or other type
instead of range where we just say if a task is latency-sensitive or not
and won't classify if a task is "relatively" latency-nice than others?

Best,
Parth