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;
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?
* Stephen Baker ([email protected]) 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
/* 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
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 ([email protected]) 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");
>}
>
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...
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.