Linux Kernel Patch; setpriority

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

@@ -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;

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?

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

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.

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

/* 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");
}

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

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

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 <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.