From owner-freebsd-hackers Tue Feb 23 17:42:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id A5FE411AAD for ; Tue, 23 Feb 1999 17:42:35 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id SAA20219; Tue, 23 Feb 1999 18:42:29 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp02.primenet.com, id smtpd019993; Tue Feb 23 18:42:10 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id SAA25033; Tue, 23 Feb 1999 18:42:06 -0700 (MST) From: Terry Lambert Message-Id: <199902240142.SAA25033@usr09.primenet.com> Subject: Re: Panic in FFS/4.0 as of yesterday To: mjacob@feral.com Date: Wed, 24 Feb 1999 01:42:05 +0000 (GMT) Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.org In-Reply-To: from "Matthew Jacob" at Feb 22, 99 08:31:05 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The only problem with this approach is not all I/O is or will be driven > by a process. Let's say we port a new filesystem in that creates a > *lot* of I/O via threads or wads of async r/w. Unless you start doing > thread scheduling it's hard to figure out whome to penalize. I think this would be an evil thing (kernel threads). The idea that you have an atomic context semi-precludes preemption without a lot of redesign work. On the plus side, it might force a redesign, but I doubt the code would make it in if that happened. > I still would like to see a B_EXPEDITE (although B_PRIORITY seems a better > name). Should we also be paying attention to B_ORDERED and should you > consider doing buffer generations? I stayed away from B_PRIORITY because that implies a spectrum of priority levels, not just an "I may be slow, but I'm in front of you". Passing the bits down is somewhat problematic, since they are pretty much stripped before they get there. It's really an interface isolation issue that I think would be very hard to deal with. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message