linux-kernel - Re: resend: KERNEL BUG: nice level should not affect SCHED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 Mar 2007 20:27:16 +1100
From:	Con Kolivas <kernel@...ivas.org>
To:	"Chris Friesen" <cfriesen@...tel.com>
Cc:	Robert Love <rml@...ell.com>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...l.org>,
	Linux kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>
Subject: Re: resend: KERNEL BUG: nice level should not affect SCHED_RR timeslice

On Thursday 08 March 2007 10:19, Chris Friesen wrote:
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/