linux-kernel - 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>] [day] [month] [year] [list]

Message-ID: <45ED8C13.5020401@nortel.com>
Date:	Tue, 06 Mar 2007 09:43:15 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	Ingo Molnar <mingo@...e.hu>,
	Linux kernel <linux-kernel@...r.kernel.org>
Subject: resend: 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/