bitcoind - possibly process priority bug?

[asdfman]

This is kind of a continuation of this thread : http://bitcointalk.org/index.php?topic=72.0

I believe there might be a misunderstanding regarding the code for changing the process priorities... basically in short, I believe the intention is to set the processes to lowest priority (meaning most non intrusive, least priority in cpu scheduling) when the thread generating coins as it is very CPU intensive, and if not set to low priority, will noticeably decrease system responsiveness..

in main.cpp, there are multiple points in which the priority is changed to "lowest":

Code:

    while (fGenerateBitcoins)
    {
        SetThreadPriority(THREAD_PRIORITY_LOWEST);

in util.h THREAD_PRIORITY_LOWEST is set to PRIO_MIN:

Code:

#define THREAD_PRIORITY_LOWEST          PRIO_MIN

however, PRIO_MIN == the "minimum" in raw numeric terms (as in -20 < 20), but this actually means the highest priority in terms of how the OS interprets the number for the purpose of CPU scheduling

in the kernel sources resource.h:

Code:

#define PRIO_MIN        (-20)
#define PRIO_MAX        20

"A niceness of −20 is the highest priority and 19 or 20 is the lowest priority."

- http://en.wikipedia.org/wiki/Nice_(Unix)

I believe that THREAD_PRIORITY_LOWEST should be set to PRIO_MAX, otherwise the bitcoind starts disrupting system usabilty during coin generation..


Thanks
asdfman

[laszlo]

This is fixed in SVN but I think that was after the release was cut. 

The workaround is to run bitcoin like:

nice -n 19 ./bitcoind

..otherwise it hogs the CPU as you noted.

I spent some time experimenting with this and contrary to what the documentation states, on ubuntu you can actually adjust the priority to be more favorable (numerically lower) after raising it to a higher number.  I believe this might be due to selinux?  That seems non standard and I think on any 'normal' system using the usual behavior the generating thread will end up staying at the less favorable (numerically higher) priority even when an attempt to change it is made.

[asdfman]

hmm.. the problem is, even if you set nice in the beginning or use renice, the 2 generating coin threads will move back to higher priority, do a ps -efL (in most modern linux distros anyway) to see the complete ps list for all threads, and you'll see the main process with the 'nice' setting, but other threads changing the priority...

for example in the other thread I posted in, http://bitcointalk.org/index.php?topic=72.0, in my process list copy/paste, the main process kept the nice value, and even if i manually niced the other threads, they would change automatically back to higher priority both in the listing, and I would definitely notice the degredation in my system responsiveness

Ive completely ripped out the priority changing function as Id prefer to set it myself and not have the program change it from what I want..

[laszlo]

Are you using some sort of alternate permission framework like selinux?  I believe some linux distros like ubuntu come with this by default.  Per the man page for setpriority (even on ubuntu), only root can lower (make more favorable) the priority so it should not be possible for the adjustment to work on linux.  Anyway the reason it tries to raise its scheduling priority is so that it can quickly save a generated block and then go back to low priority for generating again.  Your issues should all be fixed in SVN and you shouldn't have to manually set the priority anymore - you can just change the PRIO_MIN to your preferred priority, or use the PRIO_MAX macro.

http://www.kernel.org/doc/man-pages/online/pages/man2/getpriority.2.html

       The getpriority() call returns the highest priority (lowest numerical value)
       enjoyed by any of the specified processes.  The setpriority() call sets the
       priorities of all of the specified processes to the specified value.  Only the
       superuser may lower priorities.

[brightside]

Thank you for the information. 

I attempted running bitcoind on my server today (Ubuntu 10.04), worked fine while it was downloading blocks but after a while it the ssh session stopped responding and even network pings went unanswered, so I had to do a manual shutdown and restart to get it under control again. Will try recompiling with the PRIO_MAX setting.