Messages in this thread | | | Subject | Re: [PATCH 2/4] sched: set new prio after checking schedule policy | From | Dietmar Eggemann <> | Date | Thu, 30 Apr 2020 16:06:15 +0200 |
| |
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 ...
| |