[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250714085901.GN905792@noisy.programming.kicks-ass.net>
Date: Mon, 14 Jul 2025 10:59:01 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Juri Lelli <juri.lelli@...hat.com>
Cc: Ingo Molnar <mingo@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Valentin Schneider <vschneid@...hat.com>,
Waiman Long <llong@...hat.com>, linux-kernel@...r.kernel.org,
Marcel Ziswiler <marcel.ziswiler@...ethink.co.uk>,
Luca Abeni <luca.abeni@...tannapisa.it>
Subject: Re: [PATCH 3/5] sched/deadline: Fix accounting after global limits
change
On Fri, Jun 27, 2025 at 01:51:16PM +0200, Juri Lelli wrote:
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> index 15d5855c542cb..be6e9bcbe82b6 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -2886,6 +2886,12 @@ static int sched_rt_handler(const struct ctl_table *table, int write, void *buff
> sched_domains_mutex_unlock();
> mutex_unlock(&mutex);
>
> + /*
> + * After changing maximum available bandwidth for DEADLINE, we need to
> + * recompute per root domain and per cpus variables accordingly.
> + */
> + rebuild_sched_domains();
> +
> return ret;
> }
So I'll merge these patches since correctness first etc. But the above
is quite terrible. It would be really good not to have to rebuild the
sched domains for every rt change. Surely we can iterate the existing
domains and update stuff?
Powered by blists - more mailing lists