[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241203111819.GB21636@noisy.programming.kicks-ass.net>
Date: Tue, 3 Dec 2024 12:18:19 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Dietmar Eggemann <dietmar.eggemann@....com>
Cc: Vincent Guittot <vincent.guittot@...aro.org>, 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, 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
>
> (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!
Powered by blists - more mailing lists