Date: 31 Mar 2000 20:13:07 -0000 From: trost@cloud.rain.com To: FreeBSD-gnats-submit@freebsd.org Subject: kern/17714: possible priority inversion with use of idprio Message-ID: <20000331201307.82279.qmail@grey.cloud.rain.com>
next in thread | raw e-mail | index | archive | help
>Number: 17714 >Category: kern >Synopsis: possible priority inversion with use of idprio >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Mar 31 12:20:01 PST 2000 >Closed-Date: >Last-Modified: >Originator: Bill Trost >Release: FreeBSD 4.0-20000208-CURRENT i386 >Organization: Trost Computing >Environment: Uhh...single 400 MHz Pentium, single IDE drive...not sure what else would matter. >Description: I have a startup script that starts setiathome at an idprio of 31 and then starts up gf_client (a distributed gamma ray flux project) at an idprio of 30. After startup, I noticed that "ps" had an "L" flag in the "STAT" column for setiathome (the lowest priority process). The next command, "man ps", hung; then, "date" (or, more likely, the shell) hung in another window. At this point, I interrupted gf_client, and everything started working again. I presume that the problem was cause by a priority inversion where the setiathome client had somehow locked a page, but could not do whatever needed to be done with the page because gf_client was taking all available CPU cycles. >How-To-Repeat: Hah! Good luck! I have no idea how to make a process keep pages locked in core long enough to cause the problem. >Fix: I would guess that locking a page in core should cause an increase in the process's priority, but I know nothing of the details. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000331201307.82279.qmail>