Date: Thu, 21 Feb 2002 17:06:08 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Julian Elischer <julian@elischer.org>, <arch@FreeBSD.ORG> Subject: Re: Prioritized bio patches. (Updated patch) Message-ID: <200202220106.g1M168p12213@apollo.backplane.com> References: <20020219194142.M12686-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I was thinking potentially of some sort of priority stealing
mechanism similar to the mechanism that exists for mutexes.
It would not be easy to implement though. We would have to
deal with vnode locks as well as buffer locks.
Priority inversion can be a serious problem, especially in more
heavily loaded systems. I don't think it would be safe to commit
a bio priority mechanism without dealing with the problem.
Another possibility is to guarentee that the I/O request will
eventually go out by slowly bumping up its priority in the queue,
so it doesn't get stuck indefinintely.
-Matt
Matthew Dillon
<dillon@backplane.com>
: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?200202220106.g1M168p12213>