Date: Fri, 22 Feb 2002 00:27:40 -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: <20020222001512.A38875-100000@mail.chesapeake.net> In-Reply-To: <200202220106.g1M168p12213@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I agree, it is definately a problem. phk also pointed out that B_ORDERED breakage. This is really only used by ffs w/o softupdates now though. I was thinking of a trivial time slicing mechanism where you could guarantee a certain number of IOs per 100 to each queue. phk also pointed me to some interesting research on the topic. The document describes anticipatory scheduling, and is very applicable to the problem at hand. It looks like it's freely redistributable so I'll post the link here. http://phk.freebsd.dk/misc/antsched.pdf On a side note, even when our system is running at peak capacity (31MB/s per disk), lower priority IO gets a chance to go through. This is partially due to our long sim queue in cam. The interrupt latency in current is so bad that large ammounts of work get cleared out at once. Since this happens before we have a chance to issue new requests, the low priority ones make it through. Anyway, thanks for the feedback. I'll consider these comments and see if I can come up with a more optimal solution (or just steal the one presented in the paper, if the work is properly licensed). Jeff On Thu, 21 Feb 2002, Matthew Dillon wrote: > 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?20020222001512.A38875-100000>