Re: [PATCH 2/2] sched: allow users with rtprio rlimit to change fromSCHED_IDLE policy

From: Darren Hart
Date: Wed Feb 23 2011 - 11:07:49 EST


On 02/23/2011 08:00 AM, Peter Zijlstra wrote:
On Wed, 2011-02-23 at 07:52 -0800, Darren Hart wrote:
On 02/23/2011 03:17 AM, Peter Zijlstra wrote:
On Wed, 2011-02-23 at 12:13 +0100, Ingo Molnar wrote:
* Peter Zijlstra<peterz@xxxxxxxxxxxxx> wrote:

On Tue, 2011-02-22 at 13:04 -0800, Darren Hart wrote:
As it stands, users with rtprio rlimit permissions can change their policy from
SCHED_OTHER to SCHED_FIFO and back. They can change to SCHED_IDLE, but not back
to SCHED_FIFO. If they have the rtprio permission, they should be able to. Once
in SCHED_FIFO, they could go back to SCHED_OTHER. This patch allows users with
rtprio permission to change out of SCHED_IDLE.


Ingo, can you remember the rationale for this?

The fact is that SCHED_IDLE is very near nice-20, and we can do:

peterz@twins:~$ renice 5 -p $$
1867: old priority 0, new priority 5
peterz@twins:~$ renice 0 -p $$
1867: old priority 5, new priority 0

Which would suggest that we should be able to return to SCHED_OTHER
RLIMIT_NICE-20.

I dont remember anything subtle there - most likely we just forgot about that spot
when adding RLIMIT_RTPRIO support.

Ah, I was arguing we should allow it regardless of RLIMIT_RTPRIO, based
on RLIMIT_NICE, it is after all a change to SCHED_OTHER, not
SCHED_FIFO/RR.

So we need an OR test of RLIMIT_NICE | RLIMIT_RTPRIO ?

Just RLIMIT_NICE I think.

The reason I keep
coming back to RTPRIO is it allows the user to change to
SCHED_(FIFO|RR), and from there they can change to anything they want -

Hmm,. is that so? I would think that even if you're SCHED_FIFO changing
back to SCHED_OTHER ought to make you respect RLIMIT_NICE.

That is, even if you're a SCHED_FIFO-1 task due to RLIMIT_RTPRIO, when
you switch back to SCHED_OTHER I would expect you not to be able to
switch to a lower nice than RLIMIT_NICE-20.

Now, if this isn't actually so I think we ought to make it so.

I was just thinking in terms of POLICY, not priority or nice level. I'll do some experimenting and see where the limits are.


so why force two steps? Perhaps the argument is to keep the meaning of
the RLIMITs precise, and if you want to go from IDLE->OTHER you had
better properly set RLIMIT_NICE - maybe I just convinced myself.

Right

Shall I respin the patch to reflect that?

Please.

Will do.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/