linux-kernel - Re: [PATCH v2 5/7] sched/fair: Take into account latency nice at wakeup

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:   Mon, 16 May 2022 17:54:31 -0700
From:   Josh Don <joshdon@...gle.com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Benjamin Segall <bsegall@...gle.com>,
        Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Valentin Schneider <vschneid@...hat.com>,
        linux-kernel <linux-kernel@...r.kernel.org>, parth@...ux.ibm.com,
        Qais Yousef <qais.yousef@....com>,
        "Hyser,Chris" <chris.hyser@...cle.com>,
        Valentin Schneider <valentin.schneider@....com>,
        patrick.bellasi@...bug.net, David.Laight@...lab.com,
        Paul Turner <pjt@...gle.com>, pavel@....cz,
        Tejun Heo <tj@...nel.org>, Quentin Perret <qperret@...gle.com>,
        Tim Chen <tim.c.chen@...ux.intel.com>
Subject: Re: [PATCH v2 5/7] sched/fair: Take into account latency nice at wakeup

Hi Vincent,

On Thu, May 12, 2022 at 9:36 AM Vincent Guittot
<vincent.guittot@...aro.org> wrote:
>
> Take into account the nice latency priority of a thread when deciding to
> preempt the current running thread. We don't want to provide more CPU
> bandwidth to a thread but reorder the scheduling to run latency sensitive
> task first whenever possible.
>
> As long as a thread didn't use its bandwidth, it will be able to preempt
> the current thread.
>
> At the opposite, a thread with a low latency priority will preempt current
> thread at wakeup only to keep fair CPU bandwidth sharing. Otherwise it will
> wait for the tick to get its sched slice.

Following up from the discussion on the prior series, I'm still not
sure why this approach is exclusive of extending the entity placement
code; I think both changes together would be useful.

By only changing the wakeup preemption decision, you're only
guaranteeing that the latency-sensitive thing on cpu won't be
preempted until the next sched tick, which can occur at any time
offset from the wakeup, from 0ns to the length of one tick. If a
latency-tolerant task wakes up with a lot of sleeper credit, it would
pretty quickly preempt a latency-sensitive task on-cpu, even if it
doesn't initially do so due to the above changes to wakeup preemption.

Adjusting place_entity wouldn't impact cpu bandwidth in steady-state
competition between threads of different latency prio, it would only
impact slightly at wakeup, in a similar but more consistent manner to
the changes above to wakeup_preempt_entity (ie. a task that is not
latency sensitive might have to wait a few ticks to preempt a latency
sensitive task, even if it was recently sleeping for a while).