From owner-freebsd-arch Tue Feb 19 16:57:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by hub.freebsd.org (Postfix) with ESMTP id 8016937B400 for ; Tue, 19 Feb 2002 16:57:26 -0800 (PST) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id g1K0vHP37459; Tue, 19 Feb 2002 19:57:17 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Tue, 19 Feb 2002 19:57:17 -0500 (EST) From: Jeff Roberson To: Matthew Dillon Cc: Julian Elischer , Subject: Re: Prioritized bio patches. (Updated patch) In-Reply-To: <200202200036.g1K0a9U64733@apollo.backplane.com> Message-ID: <20020219194142.M12686-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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