kernel bug, nice level should not affect SCHED_RR timeslice

kernel bug, nice level should not affect SCHED_RR timeslice

[Chris Friesen]

Apparently the timeslice of the SCHED_RR process varies with nice level 
the same way that it does for SCHED_OTHER.  So while niceness doesn't 
affect the priority of a SCHED_RR task, it does impact how much cpu it gets.

SUSv3 indicates, "Any processes or threads using SCHED_FIFO or SCHED_RR 
shall be unaffected by a call to setpriority()."

The code in set_user_nice() has a comment that leads me to believe the 
current behaviour is accidental (although I think the "not" in the last 
line isn't meant to be there):

/*
  * The RT priorities are set via sched_setscheduler(), but we still
  * allow the 'normal' nice value to be set - but as expected
  * it wont have any effect on scheduling until the task is
  * not SCHED_NORMAL/SCHED_BATCH:
  */

It appears that the desired behaviour is to allow setting the nice level 
of a realtime task, but to not have it affect anything until (and 
unless) it drops that realtime status.  Is this correct?

Chris