From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Hillf Danton <hdanton@sina.com>,
Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Mike Galbraith <efault@gmx.de>,
Steven Rostedt <rostedt@goodmis.org>,
Mel Gorman <mgorman@techsingularity.net>,
Vincent Guittot <vincent.guittot@linaro.org>,
Phil Auld <pauld@redhat.com>, Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH 2/4] sched: set new prio after checking schedule policy
Date: Thu, 30 Apr 2020 16:06:15 +0200 [thread overview]
Message-ID: <da5bf72d-1d50-5c5c-3bdb-113ed555dd10@arm.com> (raw)
In-Reply-To: <20200430121301.3460-1-hdanton@sina.com>
On 30/04/2020 14:13, Hillf Danton wrote:
>
> On Tue, 28 Apr 2020 17:32:45 Valentin Schneider wrote:
>>
>>> + else if (fair_policy(policy)) {
>>> + if (attr->sched_nice < MIN_NICE ||
>>> + attr->sched_nice > MAX_NICE)
>>> + return -EINVAL;
>>
>> We can't hit this with the syscall route, since we (silently) clamp those
>> values in sched_copy_attr(). setpriority() does the same. There's this
>> comment in sched_copy_attr() that asks whether we should clamp or return an
>> error; seems like the current consensus is on clamping, but then we might
>> want to get rid of that comment :)
>>
> Yes it's quite likely for me to miss the cases covered by that clamp;
> otherwise what is added does not break that consensus.
>
>>> + newprio = NICE_TO_PRIO(attr->sched_nice);
>>
>> This is new, however AFAICT it doesn't change anything for CFS (or about to
>> be) tasks since what matters is calling check_class_changed() further down.
>
> Yes it's only used by rt_effective_prio().
>
Looks like changing a SCHED_NORMAL to a SCHED_BATCH task will create a different
queue_flags value.
# chrt -p $$
pid 2803's current scheduling policy: SCHED_OTHER
pid 2803's current scheduling priority: 0
# chrt -b -p 0 $$
...
[bash 2803] policy=3 oldprio=120 newprio=[99->120] new_effective_prio=[99->120] queue_flags=[0xe->0xa]
[bash 2803] queued=0 running=0
...
But since in this example 'queued=0' it has no further effect here.
Why is SCHED_NORMAL/SCHED_BATCH (fair_policy()) now treated differently than SCHED_IDLE?
# chrt -i -p 0 $$
...
[bash 2803] policy=5 newprio=99 oldprio=120 new_effective_prio=99 queue_flags=0xe
[bash 2803] queued=0 running=0
...
next prev parent reply other threads:[~2020-04-30 14:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200424041832.11364-1-hdanton@sina.com>
[not found] ` <20200424043041.15084-1-hdanton@sina.com>
2020-04-24 13:55 ` [PATCH 1/4] sched: set p->prio reguardless of p->mm Steven Rostedt
[not found] ` <20200424043650.14940-1-hdanton@sina.com>
2020-04-28 16:32 ` [PATCH 2/4] sched: set new prio after checking schedule policy Valentin Schneider
[not found] ` <20200430121301.3460-1-hdanton@sina.com>
2020-04-30 14:06 ` Dietmar Eggemann [this message]
2020-04-30 14:18 ` Valentin Schneider
2020-04-30 15:13 ` Valentin Schneider
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=da5bf72d-1d50-5c5c-3bdb-113ed555dd10@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=efault@gmx.de \
--cc=hdanton@sina.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mgorman@techsingularity.net \
--cc=mingo@kernel.org \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.org \
/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).