Date: Fri, 26 Apr 2002 01:06:56 +0200 From: Erik Trulsson <ertr1013@student.uu.se> To: JJ Behrens <jj@nttmcl.com> Cc: 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: <20020425230656.GB10349@student.uu.se> In-Reply-To: <20020425153121.F3601@alicia.nttmcl.com> References: <200204251836.NAA41191@aurora.sol.net> <200204252115.g3PLF6c07119@apollo.backplane.com> <20020425153121.F3601@alicia.nttmcl.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 25, 2002 at 03:31:21PM -0700, JJ Behrens wrote: > 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. Almost, but not quite. In your scenario the low-priority task would get to run since the high-priority task is blocked and would thus eventually release the resource. No deadlock, no problem. The classic priority inversion that I have heard about is the following scenario: Three processes of low, medium and high priority respectively. The low-priority task locks some resource. Before this resource is released both the medium-priority and the high-proiority task starts to run. Since these have higher priority the low-priority task doesn't get any CPU. The medium-priority task is CPU-intensive and uses all CPU-time it gets (but it won't get any while the HP-task is running.) Eventually the high-priority task tries to lock the resource that the low-priority task is holding. The high-priority task is then blocked and the medium-priority task gets to run. Now the high-priority task is blocked waiting for the resource that the low-priority task is holding. The LP-task does not get to run since the MP-task has higher priority and thus can't release the resource. This means that the priority between the HP task and the MP task has in effect been inverted, since the medium priority task blocks the high-priority task from running even if there is no resource that both of them are trying to lock. The problem is that when the high-priority task got blocked trying to acquire the resource that the low-priority task held it effectively inherited the priority of the low-priority task and can therefore be preempted by the medium-priority task. To get a priority inversion like this one needs at least three tasks with different priorities. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se 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?20020425230656.GB10349>