Linux Kernel Patch; setpriority

Linux Kernel Patch; setpriority

[Stephen Baker]

All,

This patch will allow a process or thread to changes it's priority 
dynamically based on it's capabilities.  In our case we wanted to use 
threads with Linux.  To have true priorities we need root to use 
SCHED_FIFO or SCHED_RR; in many case root access is not allowed but we 
still wanted priorities.  So we started using setpriority to change a 
threads priority.  Now we used nice values from 19 to 0 which did not 
require root access.  In some cases a thread need to raise it's nice 
level and this would fail.  I also saw a note man renice(8) that said 
this bug exists.
So the following patch address this problem.  It allows any process or 
thread to raise or lower it's nice value for it's current capability. 
For example a CAP_SYS_NICE process can use 19 to -20 for it's value and 
a normal user can use 19 to 0.  By capping normal user to zero then we 
don't have any problems with conflicts with higher priority programs in 
the system since zero is the default value.

SB


--- linux-2.4.9-31/kernel/sys.c    Wed Mar 27 13:11:10 2002
+++ linux/kernel/sys.c    Wed Mar 27 13:09:36 2002
@@ -194,6 +194,12 @@
    return 0;
}

+/*
+ * Allow the process to adjust it's priority higher or lower.
+ * If the process has CAP_SYS_NICE set then we can use
+ * -20 to 19.  Otherwise we use 0 to 19 as our valid priority
+ * range.
+ */
asmlinkage long sys_setpriority(int which, int who, int niceval)
{
    struct task_struct *p;
@@ -220,7 +226,8 @@
        }
        if (error == -ESRCH)
            error = 0;
-        if (niceval < p->nice && !capable(CAP_SYS_NICE))
+        if ((niceval < 0) &&
+            (niceval < p->nice && !capable(CAP_SYS_NICE)))
            error = -EACCES;
        else
            p->nice = niceval;

Re: Linux Kernel Patch; setpriority

[David Wagner]

What's the argument why this change to the semantics of setpriority()
is a reasonable one to make?

Previously, non-root users [*] could not decrement their current priority
value (i.e., make their own processes run faster).  Now you're allowing
processes to decrement the current priority, so long as they stay within
the range 0..19.  But what if the priority had been increased by the
scheduler because this process was running a long time and taking up
a lot of CPU time?  The proposed change to the setpriority() interface
allows such a process to "cheat" and get more CPU time than it ought to
be able to receive.

It seems to me that the scheduler should be able to renice a CPU hog
to make sure that interactive processes receive good performance, and
your proposed change circumvents this.  It's one thing for a process
to decrement its priority if this process was the one who voluntarily
incremented it earlier; it's another thing if the priority value was
incremented forcibly by the OS.  If this is correct, the proposed change
doesn't look so good.

Am I overlooking something?

Re: Linux Kernel Patch; setpriority

[Mike Fedyk]

On Wed, Mar 27, 2002 at 09:19:37PM +0000, David Wagner wrote:
> What's the argument why this change to the semantics of setpriority()
> is a reasonable one to make?
> 
> Previously, non-root users [*] could not decrement their current priority
> value (i.e., make their own processes run faster).  Now you're allowing
> processes to decrement the current priority, so long as they stay within
> the range 0..19.  But what if the priority had been increased by the

> Am I overlooking something?

Yes.  (I didn't look at the patch itself) but, it should allow you to change
the *nice* value of the process.  It doesn't allow you to change the actual
priority of the process/thread.  The scheduler itself takes into account the
nice value and interactiveness (ingo's new scheduler at least...).

One thing to thing about though, is that maybe the administrator set the
user to nice value 5 and this would allow the user to get back down the the
default of 0.

One thing you could do in that case would be to set the *other* processes to
a higher priority...

Re: Linux Kernel Patch; setpriority

[Chris Wright]

* Stephen Baker (stbaker@cisco.com) wrote:
> 
> This patch will allow a process or thread to changes it's priority 
> dynamically based on it's capabilities.  In our case we wanted to use 
> threads with Linux.  To have true priorities we need root to use 
> SCHED_FIFO or SCHED_RR; in many case root access is not allowed but we 
> still wanted priorities.  So we started using setpriority to change a 
> threads priority.  Now we used nice values from 19 to 0 which did not 
> require root access.  In some cases a thread need to raise it's nice 
> level and this would fail.  I also saw a note man renice(8) that said 
> this bug exists.

hmm, SUS v3 seems to disagree.

"Only a process with appropriate privileges can lower its nice value."

and with this patch setpriority(2) is now inconsistent with nice(2)
(albeit i don't know how much longer that interface will persist in arch
independent portion of the kernel based on the comments surrounding it).

-chris

Re: Linux Kernel Patch; setpriority

[Bill Davidsen]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1486 bytes --]

  Rather than expect people who have been following this to reread I'll
put this here. I believe the capability of nice(2) setting and restoring
is (a) very seldom useful given the new scheduler, and (b) can be done
with a bit of effort and no assult on SUS by doing the nice work in a nice
thread. 

  Code is attached.

On Wed, 27 Mar 2002, Chris Wright wrote:

> * Stephen Baker (stbaker@cisco.com) wrote:
> > 
> > This patch will allow a process or thread to changes it's priority 
> > dynamically based on it's capabilities.  In our case we wanted to use 
> > threads with Linux.  To have true priorities we need root to use 
> > SCHED_FIFO or SCHED_RR; in many case root access is not allowed but we 
> > still wanted priorities.  So we started using setpriority to change a 
> > threads priority.  Now we used nice values from 19 to 0 which did not 
> > require root access.  In some cases a thread need to raise it's nice 
> > level and this would fail.  I also saw a note man renice(8) that said 
> > this bug exists.
> 
> hmm, SUS v3 seems to disagree.
> 
> "Only a process with appropriate privileges can lower its nice value."
> 
> and with this patch setpriority(2) is now inconsistent with nice(2)
> (albeit i don't know how much longer that interface will persist in arch
> independent portion of the kernel based on the comments surrounding it).

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

[-- Attachment #2: Type: TEXT/PLAIN, Size: 762 bytes --]

/* try changing nice(2) for a single thread */

#include <stdio.h>
#include <unistd.h>
#include <pthread.h>

int pid;
void part1(int *);
pthread_mutex_t print_lock = PTHREAD_MUTEX_INITIALIZER;
#define MAX_LOOP		100

main(int argc, char *argv[])
{
	int j, stat;
	volatile int i = 0;
	pthread_t thrd1;

	pid = getpid();
	fprintf(stderr, "parent pid: %d\n", pid);
	pthread_create(&thrd1, NULL, (void *)part1, (void *)&i);
	/* note that I am not doing a damn thing here */
	pthread_join(thrd1, NULL);

	fprintf(stderr, "Normal termination\n");
	exit(0);
}

void
part1(int *ix)
{
	/* do one ps before nice(2) call */
	system("ps l");
	/* now be nice and try again */
	fprintf(stderr, "\n--> nice\n");
	nice(6);
	system("ps l");
}

Re: Linux Kernel Patch; setpriority

[Stephen Baker]

Bill,

You correct, I have tried this approach before and it seem like doubling 
the work on the system.  For one your create a thread which is really a 
process to create another process; that's ok for a small app but not a 
very scalable solution considering all the code in glibc used for 
pthread_create.   This is a bigger problem is when you only have one 
thread at nice value 0 and all other are higher value.  Now you have to 
have the main thread do it's work and the check flags to see if it needs 
to create the new thread so it can have a nice value you can change.

All this is really just pigeon dancing around the fact that Linux 
doesn't implement the PTHREAD_SCOPE_PROCESS which is all I want .  I t 
would make Linux match Solaris and BSD model for POSIX threads.  I guess 
it wouldn't be POSIX if everyone implemented it the same set of 
supported features.  That's why I resorted to changing the nice value in 
hopes of have some say in how things get scheduled without all the 
superuser / capabilities hacks.

After all this info I will go back and try to find a work around. 
 Thanks Bill and Chris for the help.
SB

Bill Davidsen wrote:

>  Rather than expect people who have been following this to reread I'll
>put this here. I believe the capability of nice(2) setting and restoring
>is (a) very seldom useful given the new scheduler, and (b) can be done
>with a bit of effort and no assult on SUS by doing the nice work in a nice
>thread. 
>
>  Code is attached.
>
>On Wed, 27 Mar 2002, Chris Wright wrote:
>
>>* Stephen Baker (stbaker@cisco.com) wrote:
>>
>>>This patch will allow a process or thread to changes it's priority 
>>>dynamically based on it's capabilities.  In our case we wanted to use 
>>>threads with Linux.  To have true priorities we need root to use 
>>>SCHED_FIFO or SCHED_RR; in many case root access is not allowed but we 
>>>still wanted priorities.  So we started using setpriority to change a 
>>>threads priority.  Now we used nice values from 19 to 0 which did not 
>>>require root access.  In some cases a thread need to raise it's nice 
>>>level and this would fail.  I also saw a note man renice(8) that said 
>>>this bug exists.
>>>
>>hmm, SUS v3 seems to disagree.
>>
>>"Only a process with appropriate privileges can lower its nice value."
>>
>>and with this patch setpriority(2) is now inconsistent with nice(2)
>>(albeit i don't know how much longer that interface will persist in arch
>>independent portion of the kernel based on the comments surrounding it).
>>
>
>
>------------------------------------------------------------------------
>
>/* try changing nice(2) for a single thread */
>
>#include <stdio.h>
>#include <unistd.h>
>#include <pthread.h>
>
>int pid;
>void part1(int *);
>pthread_mutex_t print_lock = PTHREAD_MUTEX_INITIALIZER;
>#define MAX_LOOP		100
>
>main(int argc, char *argv[])
>{
>	int j, stat;
>	volatile int i = 0;
>	pthread_t thrd1;
>
>	pid = getpid();
>	fprintf(stderr, "parent pid: %d\n", pid);
>	pthread_create(&thrd1, NULL, (void *)part1, (void *)&i);
>	/* note that I am not doing a damn thing here */
>	pthread_join(thrd1, NULL);
>
>	fprintf(stderr, "Normal termination\n");
>	exit(0);
>}
>
>void
>part1(int *ix)
>{
>	/* do one ps before nice(2) call */
>	system("ps l");
>	/* now be nice and try again */
>	fprintf(stderr, "\n--> nice\n");
>	nice(6);
>	system("ps l");
>}
>

Re: Linux Kernel Patch; setpriority

[Bill Davidsen]

On Thu, 28 Mar 2002, Stephen Baker wrote:

> All this is really just pigeon dancing around the fact that Linux 
> doesn't implement the PTHREAD_SCOPE_PROCESS which is all I want .  I t 
> would make Linux match Solaris and BSD model for POSIX threads.  I guess 
> it wouldn't be POSIX if everyone implemented it the same set of 
> supported features.  That's why I resorted to changing the nice value in 
> hopes of have some say in how things get scheduled without all the 
> superuser / capabilities hacks.

  I just did a "man 3 pthreads" and that capability is listed as
available... If you can boil it down to a small test program as I did,
I'll run it on Linux and Solaris and see what I see.

  Of course Linux doesn't implement anything here, you choose the
implementation by pthreads lib and includes, the old MIT user-level one,
the so-called "Linux threads" model, or the current NGPT model in current
kernels and the library from IBM.

  The latter work, at least for some definitions of "work," but I know
there are some differences.

  I don't see why starting two threads at different priorities when the
program does init is enough overhead to notice, but I don't have your
program so you may need something inobvious.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.