Date: Thu, 25 Apr 2002 15:31:21 -0700 From: JJ Behrens <jj@nttmcl.com> To: Matthew Dillon <dillon@apollo.backplane.com>, Joe Greco <jgreco@ns.sol.net>, freebsd-stable@FreeBSD.ORG Subject: Re: kernel trap 9 with interrupts disabled Message-ID: <20020425153121.F3601@alicia.nttmcl.com> In-Reply-To: <200204252115.g3PLF6c07119@apollo.backplane.com>; from dillon@apollo.backplane.com on Thu, Apr 25, 2002 at 02:15:06PM -0700 References: <200204251836.NAA41191@aurora.sol.net> <200204252115.g3PLF6c07119@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dear Sir, > The classic priority inversion problem occurs when you have a low > priority process blocked on I/O and a higher priority process > monopolizing the cpu. Even though the lower priority process is > woken up by the kernel, it doesn't get cpu until there are no > runnable higher priority processes and so it is unable to release > any locks it might have been holding for the I/O. I beg to differ. As I know it, the priority inversion problem occurs when a lower priority process owns a resource that a higher priority process blocks on. The lower priority process cannot run because it has a lower priority, and the higher priority process cannot run because it is blocked on a resource--thus deadlock. Reading below, I think you understand this, but got mixed up in the details. > The FreeBSD-stable scheduler will dynamically alter the priority of a > running process, which prevents the priority inversion from locking up > the machine when all the processes in question are on the normal > scheduler queue. But it can't cross priority queues so if you have > a process on the idle priority queue it can get 'stuck' in > a system call while holding a lock (like on a directory vnode or > something) and then never get the cpu *at* *all* while other normal > processes are monopolizing the cpu. As other normal processes try > to obtain the lock they block, locking the whole system up > (except for the higher priority processes monopolizing the cpu, > but for all intents and purposes the system is locked up). > > I believe FreeBSD-current solves this problem by aggregating > the three priority queues we had in -stable into a single queue > for -current, and then allowing a higher priority process to > 'lend' its priority to a lower priority process that is holding > a lock that the higher priority process wants. I don't know if > it's been 100% implemented yet. You could ask John (JHB). Yes, the solution to priority inversion is priority inheritance. Priority inheritance allows the higher priority process to lend its priority level to the lower priority process so that it may finish its job and release the resource that the original higher priority process requires. > In your case I'm sure the normal priority 'nit' and other > cpu intensive processes combined with the idprio setiathome > processes are creating this problem. I recommend either not > running setiathome, or running it with a normal NICE (like nice +19). > Alternatively you might consider running -current but I would not > recommend it for a production environment yet. Yeah, setiathome is definitely something that should be nice +19'd. Afterall, you only want the computer to work on setiathome when it's not doing anything else. Best Regards, -jj -- Users of C++ should consider hanging themselves rather than shooting their legs off--it's best not to use C++ simply as a better C. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020425153121.F3601>