linux-kernel - Re: [PATCH 0/11 v3] sched/fair: Fix statistics with delayed dequeue

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]

Message-ID: <CAKfTPtDsR=Jha0atajjcYAvPSQ5y8gDX8orGUWuZ6MO7OOt4xA@mail.gmail.com>
Date: Tue, 3 Dec 2024 14:37:57 +0100
From: Vincent Guittot <vincent.guittot@...aro.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Dietmar Eggemann <dietmar.eggemann@....com>, mingo@...hat.com, juri.lelli@...hat.com, 
	rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de, vschneid@...hat.com, 
	linux-kernel@...r.kernel.org, kprateek.nayak@....com, pauld@...hat.com, 
	efault@....de, luis.machado@....com, tj@...nel.org, void@...ifault.com
Subject: Re: [PATCH 0/11 v3] sched/fair: Fix statistics with delayed dequeue

On Tue, 3 Dec 2024 at 12:18, Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Tue, Dec 03, 2024 at 11:41:47AM +0100, Dietmar Eggemann wrote:
>
> > with the following nits:
> >
> > (1) 01/11
> >
> >     Proposed 'Fixes:' missing:
> >     https://lkml.kernel.org/r/c82ed217-cfe4-41a4-b39a-e7356231835f@amd.com

Yeah i  forgot to add the fix tag
Fixes: 11cc374f4643b ("sched_ext: Simplify scx_can_stop_tick()
invocation in sched_can_stop_tick()")

> >
> > (2) 08/11
> >
> >     Would be helpful to point out that we lost the only use case for
> >     'cfs_rq->idle_nr_running' with the advent of EEVDF with:
> >
> >     5e963f2bd465 - sched/fair: Commit to EEVDF
>
> Done.
>
> > (3) Using nr_running on rq/rt_rq/dl_rq and nr_queued
> >     for cfs_rq might look strange to the untrained eye.
>
> Yes, but keeping nr_running with new semantics would not be less
> confusing and potentially more dangerous.
>
> > Reviewed-by: Dietmar Eggemann <dietmar.eggemann@....com>
>
> Thanks!