cat /usr/include/bits/resource.h | grep "#define PRIO_" #define PRIO_MIN -20 /* Minimum priority a process can have. */ #define PRIO_MAX 20 /* Maximum priority a process can have. */ .... straced bitcoin shows smth like\ 23068 setpriority(PRIO_PROCESS, 0, 20) but nice level of 23068 stays 0 Reproducible: Always Steps to Reproduce: 1. try to set nice level in gnome-system-manager to 20 (it is available there) Actual Results: nice level stays 19 Expected Results: nice level must be 20 setpriority must set nice level 20 but after 23068 setpriority(PRIO_PROCESS, 0, 20) it stays 0
Please post your `emerge --info' too.
Created attachment 246444 [details] emerge --info http://paste.pocoo.org/show/259480/ -- pastebin version of emerge --info
Could you decide whether it sets it to 19 or leaves at 0? Because you mentioned both values in your bugreport.
I've checked POSIX and glibc manpages. It is POSIX limitation that the positive priority range is one shorter than negative one; glibc manpage strictly declares the range as -20..19. The Notes, however, show that this is mostly kernel related, and some systems in fact use -20..20. Linux is not amongst that systems, as you can see in Documentation/scheduler/sched-nice-design.txt, where it is explicitly stated that nice values range from -20 to 19. Additionally, I don't see PRIO_MIN or PRIO_MAX mentioned anywhere really. I found some Debian bugreport [1] which shows that these values are the same as in kernel headers. But a quick grep shows that they aren't used in kernel source anyway. I think you could assume that the range for priorities is <PRIO_MIN, PRIO_MAX) ∩ ℤ. If you'd like to fight for it, I'd suggest going upstream (and that's what probably the dev would do) but I can reassign the bug. Otherwise, please let me know and I'll close the bug. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=89089
in gnome-system-manager it sets 19 nistead of 20 in another program (bitcoin) after setpriority(PRIO_PROCESS, 0, 20) it stays at 0
(In reply to comment #5) > in gnome-system-manager it sets 19 nistead of 20 That's correct. That's what should happen after setpriority(PRIO_PROCESS, somepid, 1000) too. > in another program (bitcoin) after setpriority(PRIO_PROCESS, 0, 20) it stays at > 0 I don't see such a package in gx86. Could you point me to where the program comes from?
bitcoin comes from booboo overlay gnome-system-manager says that it can set 20 (max) but it sets 19...
(In reply to comment #7) > bitcoin comes from booboo overlay Ok, I've looked at its source code and I don't see anything special about it. A simple test program doing 'setpriority(PRIO_PROCESS, 0, 20)' works as expected. Thus, I assume this might be a forking/threading issue. Anyway, I can't do anything about it. About gnome-system-manager, I don't know if we can do anything either. Maybe g-s-m gets the PRIO_MAX value wrong, or maybe glibc headers are indeed wrong.
i see nothing in your output that indicates a bug in glibc. it merely exists to forward along calls to the kernel and as your strace shows, it is doing just that. as for why a process doing "setpriority(PRIO_PROCESS, 0, 20)" on itself doesnt work, that sounds like something the process opted in for and the kernel is enforcing it, or the kernel is broken in someway. you can try simple kernel calls yourself: #include <sys/syscall.h> main() { syscall(__NR_getpriority, 0, 0); syscall(__NR_setpriority, 0, 0, 200); syscall(__NR_getpriority, 0, 0); } stracing that on a simple process shows: getpriority(PRIO_PROCESS, 0) = 20 setpriority(PRIO_PROCESS, 0, 200) = 0 getpriority(PRIO_PROCESS, 0) = 1 the return value of the getpriority() syscall is biased so that it always returns a positive value. so you have to take the kernel returned value, subtract it from 20, and that will tell you the nice level (i.e. prio = 20 - getpriority()). the process started out with a nice level of 0, so the kernel returned 20 (20 - 20 == 0). then the process raised itself to a really large value, but the kernel only allowed it up to 19 (20 - 19 == 1). look at the 19th field of /proc/.../pid if you want to double check: $ awk '{print $19}' /proc/`pidof a.out`/stat 19
Well, gnome team only maintained gnome-system-monitor, then, this bug will be used for handling it. About "bitcoin", you should contact its upstream or, at least, the maintainer of that unofficial overlay. Regarding the issue with gnome-system-monitor, I would probably open a bug to upstream: bugzilla.gnome.org (system-monitor product)
Reported to upstream, we will track the issue there: https://bugzilla.gnome.org/show_bug.cgi?id=640755
