On Thursday 08 March 2007 10:19, Chris Friesen wrote:
quoted text
> I still haven't seen any replies, so I'm resending with a few more
> people directly in the TO list.
>
> The timeslice of a SCHED_RR process currently varies with nice level the
> same way that it does for SCHED_OTHER.  I've included a small app below
> that demonstrates the issue.  So while niceness doesn't affect the
> priority of a SCHED_RR task, it does impact how much cpu it gets
> relative to other SCHED_RR tasks.
>
> SUSv3 indicates, "Any processes or threads using SCHED_FIFO or SCHED_RR
> shall be unaffected by a call to setpriority()."
>
> In addition, 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 of the comment 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.  This seems reasonable, but
> doesn't match current behaviour.

Chris. 

Indeed we do change timeslice with nice on rt_tasks in mainline at the moment. 
Truth is most rt programming couldn't care less about timeslices, but your 
point about it deviating from the standard is valid. RSDL does not change 
timeslice with nice on SCHED_RR tasks so it's sort of getting addressed by 
proxy.

-- 
-ck
-
unsubscribe notice
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/