mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Qais Yousef <qais.yousef@arm.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
	Patrick Bellasi <patrick.bellasi@matbug.net>,
	Tejun Heo <tj@kernel.org>, Quentin Perret <qperret@google.com>,
	Wei Wang <wvw@google.com>, Yun Hsiang <hsiang023167@gmail.com>,
	Xuewen Yan <xuewen.yan94@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/uclamp: Fix uclamp_tg_restrict()
Date: Wed, 16 Jun 2021 19:09:26 +0200	[thread overview]
Message-ID: <0b47fb7f-c96b-c2d6-e5e4-9a63683d6d56@arm.com> (raw)
In-Reply-To: <20210611122246.3475897-1-qais.yousef@arm.com>

On 11/06/2021 14:22, Qais Yousef wrote:
> Now cpu.uclamp.min acts as a protection, we need to make sure that the
> uclamp request of the task is within the allowed range of the cgroup,
> that is it is clamp()'ed correctly by tg->uclamp[UCLAMP_MIN] and
> tg->uclamp[UCLAMP_MAX].
> 
> As reported by Xuewen [1] we can have some corner cases where there's
> inverstion between uclamp requested by task (p) and the uclamp values of

s/inverstion/inversion

[...]

> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 9e9a5be35cde..0318b00baa97 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1403,38 +1403,28 @@ static void uclamp_sync_util_min_rt_default(void)
>  static inline struct uclamp_se
>  uclamp_tg_restrict(struct task_struct *p, enum uclamp_id clamp_id)
>  {
> -	struct uclamp_se uc_req = p->uclamp_req[clamp_id];
> +	/* Copy by value as we could modify it */
> +	struct uclamp_se uc_eff = p->uclamp_req[clamp_id];
>  #ifdef CONFIG_UCLAMP_TASK_GROUP
> +	unsigned int tg_min, tg_max, value;
>  
>  	/*
>  	 * Tasks in autogroups or root task group will be
>  	 * restricted by system defaults.
>  	 */
>  	if (task_group_is_autogroup(task_group(p)))
> -		return uc_req;
> +		return uc_eff;
>  	if (task_group(p) == &root_task_group)
> -		return uc_req;
> +		return uc_eff;
>  
> -	switch (clamp_id) {
> -	case UCLAMP_MIN: {
> -		struct uclamp_se uc_min = task_group(p)->uclamp[clamp_id];
> -		if (uc_req.value < uc_min.value)
> -			return uc_min;
> -		break;
> -	}
> -	case UCLAMP_MAX: {
> -		struct uclamp_se uc_max = task_group(p)->uclamp[clamp_id];
> -		if (uc_req.value > uc_max.value)
> -			return uc_max;
> -		break;
> -	}
> -	default:
> -		WARN_ON_ONCE(1);
> -		break;
> -	}
> +	tg_min = task_group(p)->uclamp[UCLAMP_MIN].value;
> +	tg_max = task_group(p)->uclamp[UCLAMP_MAX].value;
> +	value = uc_eff.value;
> +	value = clamp(value, tg_min, tg_max);
> +	uclamp_se_set(&uc_eff, value, false);
>  #endif
>  
> -	return uc_req;
> +	return uc_eff;
>  }

I got confused by the renaming uc_req -> uc_eff.

We have:

uclamp_eff_value()                                     (1)

  uclamp_se  uc_eff = uclamp_eff_get(p, clamp_id);     (2)

    uclamp_se uc_req = uclamp_tg_restrict(p, clamp_id) (3)

      struct uclamp_se uc_eff = p->uclamp_req[clamp_id];
      ....

(3) is now calling it uc_eff where (2) still uses uc_req for the return
of (3). IMHO uc_*eff* was used after the system level (
uclamp_default) have been applied.

[...]

> @@ -1670,10 +1659,8 @@ uclamp_update_active_tasks(struct cgroup_subsys_state *css,
>  
>  	css_task_iter_start(css, 0, &it);
>  	while ((p = css_task_iter_next(&it))) {
> -		for_each_clamp_id(clamp_id) {
> -			if ((0x1 << clamp_id) & clamps)
> -				uclamp_update_active(p, clamp_id);
> -		}
> +		for_each_clamp_id(clamp_id)
> +			uclamp_update_active(p, clamp_id);
>  	}
>  	css_task_iter_end(&it);
>  }
> @@ -9626,7 +9613,7 @@ static void cpu_util_update_eff(struct cgroup_subsys_state *css)
>  		}
>  
>  		/* Immediately update descendants RUNNABLE tasks */
> -		uclamp_update_active_tasks(css, clamps);
> +		uclamp_update_active_tasks(css);

Since we now always have to update both clamp_id's, can you not update
both under the same task_rq_lock() (in uclamp_update_active())?

  parent reply	other threads:[~2021-06-16 17:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-11 12:22 Qais Yousef
2021-06-16  3:06 ` Xuewen Yan
2021-06-17  8:58   ` Qais Yousef
2021-06-16 17:09 ` Dietmar Eggemann [this message]
2021-06-17  9:02   ` Qais Yousef

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0b47fb7f-c96b-c2d6-e5e4-9a63683d6d56@arm.com \
    --to=dietmar.eggemann@arm.com \
    --cc=hsiang023167@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=patrick.bellasi@matbug.net \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=qperret@google.com \
    --cc=tj@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=wvw@google.com \
    --cc=xuewen.yan94@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®