Messages in this thread | | | Date | Mon, 05 Mar 2007 14:02:08 -0600 | From | "Chris Friesen" <> | Subject | kernel bug, nice level should not affect SCHED_RR timeslice |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |