From owner-freebsd-arch Thu Feb 21 17: 6:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0DC5637B400 for ; Thu, 21 Feb 2002 17:06:15 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1M168p12213; Thu, 21 Feb 2002 17:06:08 -0800 (PST) (envelope-from dillon) Date: Thu, 21 Feb 2002 17:06:08 -0800 (PST) From: Matthew Dillon Message-Id: <200202220106.g1M168p12213@apollo.backplane.com> To: Jeff Roberson Cc: Julian Elischer , Subject: Re: Prioritized bio patches. (Updated patch) References: <20020219194142.M12686-100000@mail.chesapeake.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 :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