From owner-freebsd-hackers Wed Jan 21 17:19:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA22571 for hackers-outgoing; Wed, 21 Jan 1998 17:19:42 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA22565 for ; Wed, 21 Jan 1998 17:19:36 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id UAA12943; Wed, 21 Jan 1998 20:19:07 -0500 (EST) (envelope-from toor) Message-Id: <199801220119.UAA12943@dyson.iquest.net> Subject: Re: Locking on disk slice I/O--yes, no or how? In-Reply-To: from Michael Hancock at "Jan 22, 98 10:02:14 am" To: michaelh@cet.co.jp (Michael Hancock) Date: Wed, 21 Jan 1998 20:19:07 -0500 (EST) Cc: tlambert@primenet.com, grog@lemis.com, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk Michael Hancock said: > On Wed, 21 Jan 1998, Terry Lambert wrote: > > > Only if you have an intention collision would you resort to a TSM > > call to resolve the collision. For the most part, it's non-blocking. > > TSM doesn't necessarily mean it's non-blocking. It just means that a > vnode you're about to modify won't suddenly become a mbuf. Intent locking > seems similar in this respect. Maybe I'm being a smartass, but since John > said TSM instead of NBS it leaves it open to speculation a wee bit. > > Things sure are getting interesting in current! > The use of TSM and generation counters will mostly be to verify the state of queues and the associated datastructures during traversal. This will allow us to keep from restarting at the beginning after potentially blocking operations. There will be other advantages of the usage of TSM, and perhaps we'll be able to learn to avoid blocking in certain circumstances. It just seems that it is a good idea to use TSM for various reasons. TSM is yet another tool in our "toolkit." TSM will also allow us to improve the performance of various kernel operations, so that we don't have to fully re-initialize data structures every time that we use them. I am also looking at pushing certain kernel services into kernel threads (AIO is already there), but those things are off into the future (probably 3.1+ timeframe.) -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig.