Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Feb 2002 19:57:17 -0500 (EST)
From:      Jeff Roberson <jroberson@chesapeake.net>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Julian Elischer <julian@elischer.org>, <arch@FreeBSD.ORG>
Subject:   Re: Prioritized bio patches. (Updated patch)
Message-ID:  <20020219194142.M12686-100000@mail.chesapeake.net>
In-Reply-To: <200202200036.g1K0a9U64733@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On Tue, 19 Feb 2002, Matthew Dillon wrote:

>
>     Jeff, this looks like really interesting stuff!  Could you explain
>     the starvation issues in more depth?  e.g. if I have a nice+20 process
>     doing disk I/O and a nice-20 process saturating the disk, is it possible
>     for the nice-20 process to lockout the nice+20 process from doing
>     any disk I/O?
>
>     Another worry: what happens when a low priority process is holding a
>     vnode lock while doing synchronous I/O and a high priority process wants
>     to access the same vnode?  Here I am specifically thinking about
>     directory accesses that are incidental to a path lookup.
>
> 						-Matt
>

Yes, there is a possibility that a high priority process will completely
lock out the low priority process.  I haven't followed recent scheduler
changes, but a niced process may never run at all if there is real work
no?  If this is true, than the two are very similar.  Anyhow, there is a
definite priority inversion issue here, but the system is somewhat
autobalancing.  One would assume that the higher priority task is blocked
waiting for the low priority task to finish.  So it is not issuing any
other io, which allows the low priority task to finish up.  This is not
entirely optimal, I agree.  I can not check for priority inversion with
lockmgr locks though, so there really is no obvious way out.

For my application, the lockout was very desirable.  With workloads such
as compiling, you'll always have some free slots to send low priority io.
This is due to the sequential nature of the workload though.  It reads,
does something with the data, and then writes.  In between other things
can happen.  I could see how a very busy database or web server may never
give nice processes a chance to finish(until late at night, perhaps).

You could force all file system meta data operations to run at the normal
priority.  This would be good for directory operations in  particular. You
can still have priority inversion issues with individual  file
read/writes, but it would alleviate some of the problems.


Jeff



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020219194142.M12686-100000>