Currently, seti@home binary(ies) run nice-ly but they can still interfere with machine's main purpose(s). Using idprio may help reduce the interference.
Responsible Changed From-To: freebsd-ports->stb Over to MAINTAINER
State Changed From-To: open->closed idprio shouldn't be used by default because idprio doesn't work correctly. It has known priority inversion problems that will eventually machines to lookup. I thought about simply suggesting that the port user be given the option to use idprio, with "no" as the default answer, but, really, idprio shouldn't be used at all. See kern/5641, as well as comments in sys/kern/kern_synch.c particularly function maybe_resched().
On 20 May, hoek@FreeBSD.org wrote: = Synopsis: running set@home with idprio = = State-Changed-From-To: open->closed = State-Changed-Why: = idprio shouldn't be used by default because idprio doesn't work = correctly. It has known priority inversion problems that will = eventually machines to lookup. = = I thought about simply suggesting that the port user be given the = option to use idprio, with "no" as the default answer, but, really, = idprio shouldn't be used at all. = = See kern/5641, as well as comments in sys/kern/kern_synch.c particularly = function maybe_resched(). Two points: . The suggested PR originated on 2.2.5 and describes an entirely different scenario: Run a process with idprio that accesses the disk a lot. Run a cpu-bound process at normal priority Seti@home does NOT access the disk a lot. It is a cpu-bound process. . I run it at idprio on all of my 4.0 machines for weeks already -- seems fine. See http://setiathome.ssl.berkeley.edu/cgi-bin/cgi?email=mi%2Bseti%40aldan.algebra.com&cmd=user_stats That said, may be, indeed there is a danger and I was simply lucky so far... -mi
On Mon, May 22, 2000 at 10:38:23AM -0400, mi@privatelabs.com wrote: > = > = See kern/5641, as well as comments in sys/kern/kern_synch.c particularly > = function maybe_resched(). > > Two points: > . The suggested PR originated on 2.2.5 and describes an entirely > different scenario: See comments in sys/kern/kern_synch.c. -- Signature withheld by request of author.