On Wed, Jun 27, 2007 at 02:01:17PM +1000, Daniel Carosone wrote:
> On Tue, Jun 26, 2007 at 08:42:12PM -0700, Jason Thorpe wrote:
> > 
> >  On Jun 26, 2007, at 5:38 PM, Andrew Doran wrote:
> > 
> > > It will make it simpler. As I said there's a lot of confusion between
> > > what's covered by the long term lock that Unix has had ~forever (B_BUSY),
> > > and the short term lock (b_interlock) which is fairly recent. I suspect
> > > that softdep has contributed to that: it's the only substantial chunk of
> > > file system code that's run from an interrupt handler.
> > 
> >  ...and that needs to just die.  No part of the file system should ever run 
> >  in an interrupt handler.

If it was down to me I'd remove softdep outright, but people have different
requirements.

> Lots of small bits of it do (from biodone).  We've hit this before (eg
> via cgd-on-vnd). Softdep is just the substantial example that adds
> work there.
> 
> Getting the locking straightened out will let it move somewhere else
> (kthread(s), continuations/callbacks, tasks in a deeper/smarter io
> queue/scheduler like zfs uses, or whatever).
> 
> "Cheating" by moving biodone itself to a workqueue+thread(s) might be
> worth looking at, if it helps get them out of the big lock and hence
> possibly improve concurrency.

Deferring biodone's work to a kthread in the general case is in my opinion
too expensive. Where there's more complicated work to be done I think it
makes sense. On the vmlocking branch, biodone defers work to a (threaded)
soft interupt, which does most of what a kthread would do anyway (although
soft interrupts being in limited supply, it needs to be quick).

http://nxr.netbsd.org/source/xref/sys/kern/vfs_bio.c?r=1.170.2.10#1450

Andrew