[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZRXqFScg/vORHoqw@gmail.com>
Date: Thu, 28 Sep 2023 23:03:17 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Haifeng Xu <haifeng.xu@...pee.com>
Cc: peterz@...radead.org, mingo@...hat.com, vincent.guittot@...aro.org,
juri.lelli@...hat.com, dietmar.eggemann@....com,
rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
bristot@...hat.com, vschneid@...hat.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched: Filter root_task_group at the beginning
* Haifeng Xu <haifeng.xu@...pee.com> wrote:
> We can't change the weight of the root cgroup. Let's handle
> root_task_group before doing any real work including acquiring
> the shares_mutex.
>
> Signed-off-by: Haifeng Xu <haifeng.xu@...pee.com>
> ---
> kernel/sched/fair.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index a80a73909dc2..1ac2df87e070 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -12594,6 +12594,9 @@ int sched_group_set_shares(struct task_group *tg, unsigned long shares)
> {
> int ret;
>
> + if (tg == &root_task_group)
> + return -EINVAL;
> +
> mutex_lock(&shares_mutex);
> if (tg_is_idle(tg))
> ret = -EINVAL;
So what's the motivation, how common is this case?
Normally this should be a -EINVAL error code path, which sane user-space
presumably never conscisously tries to call in that fashion, right?
It's not worth optimizing pathological cases, especially
since we check for the root CG inside __sched_group_set_shares()
already:
/*
* We can't change the weight of the root cgroup.
*/
if (!tg->se[0])
return -EINVAL;
Thanks,
Ingo
Powered by blists - more mailing lists