Date: Wed, 24 Feb 1999 01:42:05 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mjacob@feral.com Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.org Subject: Re: Panic in FFS/4.0 as of yesterday Message-ID: <199902240142.SAA25033@usr09.primenet.com> In-Reply-To: <Pine.LNX.4.04.9902220824000.16179-100000@feral-gw> from "Matthew Jacob" at Feb 22, 99 08:31:05 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902240142.SAA25033>