From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Yun Hsiang <hsiang023167@gmail.com>,
Patrick Bellasi <patrick.bellasi@matbug.net>
Cc: peterz@infradead.org, linux-kernel@vger.kernel.org, qais.yousef@arm.com
Subject: Re: [PATCH v3 1/1] sched/uclamp: add SCHED_FLAG_UTIL_CLAMP_RESET flag to reset uclamp
Date: Thu, 29 Oct 2020 13:37:58 +0100 [thread overview]
Message-ID: <c59f7c85-59a2-488b-ce51-b3abee506dac@arm.com> (raw)
In-Reply-To: <20201028184143.GA886080@ubuntu>
On 28/10/2020 19:41, Yun Hsiang wrote:
> Hi Patrick,
>
> On Wed, Oct 28, 2020 at 11:11:07AM +0100, Patrick Bellasi wrote:
[...]
>> On Tue, Oct 27, 2020 at 16:58:13 +0100, Yun Hsiang <hsiang023167@gmail.com> wrote...
>>
>>> Hi Diet mar,
>>> On Mon, Oct 26, 2020 at 08:00:48PM +0100, Dietmar Eggemann wrote:
>>>> On 26/10/2020 16:45, Yun Hsiang wrote:
[...]
>>>> From: Dietmar Eggemann <dietmar.eggemann@arm.com>
[...]
>>>> +static bool uclamp_reset(enum uclamp_id clamp_id, unsigned long flags)
>>>> +{
>>
>> Maybe we can add in some comments?
>>
> I'll add these comment.
Yeah, why not.
>> /* No _UCLAMP_RESET flag set: do not reset */
>>>> + if (!(flags & SCHED_FLAG_UTIL_CLAMP_RESET))
>>>> + return false;
>>>> +
>>
>> /* Only _UCLAMP_RESET flag set: reset both clamps */
>>>> + if (!(flags & (SCHED_FLAG_UTIL_CLAMP_MIN | SCHED_FLAG_UTIL_CLAMP_MAX)))
>>>> + return true;
>>>> +
>> /* Both _UCLAMP_RESET and _UCLAMP_MIN flags are set: reset only min */
>>>> + if ((flags & SCHED_FLAG_UTIL_CLAMP_MIN) && clamp_id == UCLAMP_MIN)
>>>> + return true;
>>>> +
>>
>> /* Both _UCLAMP_RESET and _UCLAMP_MAX flags are set: reset only max */
>>>> + if ((flags & SCHED_FLAG_UTIL_CLAMP_MAX) && clamp_id == UCLAMP_MAX)
>>>> + return true;
>>
>> Since the evaluation ordering is important, do we have to better
>> _always_ use a READ_ONCE() for all flags accesses above, to ensure it is
>> preserved?
>>
>
> Is this mean that we want to use READ_ONCE to avoid compiler reordering these
> conditions?
Why would you need a READ_ONCE() on flags here?
[...]
>>>> /* Keep using defined clamps across class changes */
>>>> - if (uc_se->user_defined)
>>>> + if (!uclamp_reset(clamp_id, attr->sched_flags) &&
>>>> + uc_se->user_defined) {
>>>> continue;
>>>> + }
>>
>> I think we miss to reset the user_defined flag here.
>>
>> What about replacing the above chunk with:
>>
>> if (uclamp_reset(clamp_id, attr->sched_flags))
>> uc_se->user_defined = false;
>> if (uc-se->user_defined)
>> continue;
>>
>> ?
>
> user_defined flag will be reset later by uclamp_se_set(uc_se, value,
> false). But I agree to split it to two condition because it seems
> clearer.
IMHO it's more elegant to use uclamp_reset() in the condition next to
uc-se->user_defined and let uclamp_se_set() set uc-se->user_defined to
false later.
>>>> /*
>>>> * RT by default have a 100% boost value that could be modified
>>>> * at runtime.
>>>> */
>>>> if (unlikely(rt_task(p) && clamp_id == UCLAMP_MIN))
>>>> - __uclamp_update_util_min_rt_default(p);
>>>> + value = sysctl_sched_uclamp_util_min_rt_default;
>>
>> By removing this usage of __uclamp_updadate_util_min_rt_default(p),
>> the only other usage remaining is the call from:
>> uclamp_udpate_util_min_rt_default().
>>
>> What about an additional cleanup by in-lining the only surviving usage?
Don't see why not.
>>>> else
>>>> - uclamp_se_set(uc_se, uclamp_none(clamp_id), false);
>>>> + value = uclamp_none(clamp_id);
>>>>
>>>> + uclamp_se_set(uc_se, value, false);
>>>> }
>>>>
>>>> - if (likely(!(attr->sched_flags & SCHED_FLAG_UTIL_CLAMP)))
>>>> + if (likely(!(attr->sched_flags & SCHED_FLAG_UTIL_CLAMP)) ||
>>>> + attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_RESET) {
>>
>> The likely() above should not wrap both conditions to be effective?
>
> Got it.
I thought the likely is for no uclamp activities, i.e. policy change.
And a uclamp reset is different to a policy change. But is this likely too?
next prev parent reply other threads:[~2020-10-29 12:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-25 7:36 [PATCH v3 1/1] sched/uclamp: add SCHED_FLAG_UTIL_CLAMP_RESET flag to reset uclamp Yun Hsiang
2020-10-26 9:47 ` Dietmar Eggemann
2020-10-26 15:45 ` Yun Hsiang
2020-10-26 19:00 ` Dietmar Eggemann
2020-10-27 15:58 ` Yun Hsiang
2020-10-28 10:11 ` Patrick Bellasi
2020-10-28 11:39 ` Qais Yousef
2020-10-28 18:03 ` Patrick Bellasi
2020-10-28 18:29 ` Qais Yousef
2020-10-28 18:41 ` Yun Hsiang
2020-10-29 12:37 ` Dietmar Eggemann [this message]
2020-10-29 11:08 ` Qais Yousef
2020-10-29 13:02 ` Yun Hsiang
2020-10-29 13:06 ` Qais Yousef
2020-10-29 15:50 ` Dietmar Eggemann
2020-10-29 17:17 ` 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=c59f7c85-59a2-488b-ce51-b3abee506dac@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=hsiang023167@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patrick.bellasi@matbug.net \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.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;
as well as URLs for NNTP newsgroup(s).