From owner-freebsd-hackers Tue Feb 23 18:34:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id DF47B11755 for ; Tue, 23 Feb 1999 18:34:43 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id VAA12509; Tue, 23 Feb 1999 21:57:01 -0500 (EST) Date: Tue, 23 Feb 1999 21:56:59 -0500 (EST) From: Alfred Perlstein To: Terry Lambert Cc: mjacob@feral.com, dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: <199902240142.SAA25033@usr09.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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