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  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/

Powered by blists - more mailing lists