Date: Tue, 23 Feb 1999 21:56:59 -0500 (EST) From: Alfred Perlstein <bright@cygnus.rush.net> To: Terry Lambert <tlambert@primenet.com> Cc: mjacob@feral.com, dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday Message-ID: <Pine.BSF.3.96.990223215225.28314N-100000@cygnus.rush.net> In-Reply-To: <199902240142.SAA25033@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Feb 1999, Terry Lambert wrote: > > 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. What alternatives would you suggest? I had an idea about lock queues and cooperative work but the problem was that i couldn't figure out how to hold multiple locks. I would REALLY appreciate a repost of what you wanted to do several months ago with SMP. You wanted people with several doctorates on your team, at the time the message really confused me, but i'd love to have another shot at reading it. -Alfred 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?Pine.BSF.3.96.990223215225.28314N-100000>