bitcoin auto-renice-ing
Hi, I run bitcoin at a nice level of 20 so as not to interfere with other tasks. Every now and then, however, it seems to auto-adjust itself to nice level 2, or even 0. It this by design? Frankly, such a thing should be illegal for a linux application… it’s a bit odd to say the least.
It sets different priorities for each thread. The generate threads run at PRIO_MIN. The other threads rarely take any CPU and run at normal.
#define THREAD_PRIORITY_LOWEST PRIO_MIN #define THREAD_PRIORITY_BELOW_NORMAL 2 #define THREAD_PRIORITY_NORMAL 0
The priorities converted from Windows priorities were probably from a table like this:
“The following table shows the mapping between nice values and Win32 priorities. Refer to the Win32 documentation for SetThreadPriority() for more information on Win32 priority issues.
nice value Win32 Priority
-20 to -16 THREAD_PRIORITY_HIGHEST
-15 to -6 THREAD_PRIORITY_ABOVE_NORMAL
-5 to +4 THREAD_PRIORITY_NORMAL
+5 to +14 THREAD_PRIORITY_BELOW_NORMAL
+15 to +19 THREAD_PRIORITY_LOWEST”
If you have better values, suggestions welcome.
Also, there was some advice on the web that PRIO_PROCESS is used on Linux because threads are processes. If that’s not true, maybe it accounts for unexpectedly setting the priority of the whole app.
// threads are processes on linux, so PRIO_PROCESS affects just the one thread setpriority(PRIO_PROCESS, getpid(), nPriority);
I think that this might be a bug… http://bitcointalk.org/index.php?topic=285.0
Asdfman, what program is generating that output? I like it Cheesy
lachesis - htop its awesome.. has ANSI colors, you can fully configure it to display all threads, tree view, etc ,etc
Laszlo corrected this, but unfortunately it was too late to make it into 0.3.0. There will probably be a 0.3.1 soon though.
The problem is I used PRIO_MIN, I should have used PRIO_MAX for the lowest priority. The OS isn’t supposed to let you increase priority, so the PRIO_MIN ought to leave it at priority 0.