On Fri, Sep 08, 2006 at 12:10:07AM +0000, YAMAMOTO Takashi wrote:
> The following reply was made to PR kern/34293; it has been noted by GNATS.
> 
> From: yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
> To: gnats-bugs@NetBSD.org
> Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
> 	netbsd-bugs@netbsd.org, mlelstv@serpens.de
> Subject: Re: PR/34293 CVS commit: src/sys/dev
> Date: Fri,  8 Sep 2006 09:06:13 +0900 (JST)
> 
>  >  If I remember previous discussions there was some opposition in
>  >  restricting writes this way. Please check the discussions about
>  >  untarring source trees and waiting for X11 to respond again.
>  
>  can you provide a pointer?

There is http://mail-index.netbsd.org/current-users/2004/08/30/0033.html,
but there are earlier threads I have to look up.


>  >  Throttling getblk does not prevent the deadlock. For that you need
>  >  to distinguish between the upper filesystem or block device, that
>  >  needs to be throttled and the lower filesystem (or rather lowest
>  >  if you start nesting deeper), that must be kept running to avoid the
>  >  deadlock.
>  >  
>  >  There is also the problem about feedback. How would you know when
>  >  to throttle (or rather when to stop)?. You could have a mechanism
>  >  that looks at all the device queues, if buffers pile up there
>  >  because the device is too slow, you stop generating more.
>  
>  the point is to avoid filling up buffer cache with dirty data.
>  ensuring that the amount of dirty data is less than, say,
>  1/2 of total buffer cache, should be enough.
>  it prevents deadlock because clean buffers can be reclaimed without i/o.
>  well, i don't claim it's a perfect solution.  but i believe it's
>  far better than your patch, which doesn't seem to make sense at all.

If you limit dirty buffers to 1/2 of total buffer cache you will
still deadlock. It doesn't matter what limit you put on dirty
buffers. Whenever that limit it reached then vnd cannot process
them because for doing so it would have to exceed that limit. You
must make sure that the filesystem that vnd is calling through
VOP_STRATEGY _can_ allocate new buffers, even those that it
can use for writing.

If my patch doesn't make sense, then try to understand why it works.


>  >  But throttling getblk isn't good enough, you only want to throttle
>  >  getting buffers that end in the particular slow device queue. And
>  >  getblk doesn't have that information.
>  
>  the device speed doesn't matter much here.
>  once you fill buffer cache with dirty data, you lose.

No, if the blocks are allocated for another filesystem or another device,
it is perfectly possible for these to be processed. So you only want
to avoid blocks to be dirtied that end on the device that cannot
process them or at least cannot process them fast enough.


>  "the writer" here includes attempts of cleaning buffers.
>  it just introduces another deadlock.

The writer does never clean blocks. The writer can only create
more dirty blocks. The blocks are "clean" again when they
are processed by the device, i.e. in some iodone routine
which is called in an interrupt. How should a sleeping process
prevent that? In particular, at that time the writer is stopped
in vndstrategy, we definitely know that the vndthread _is_ busy
cleaning buffers, because that is the stop condition. We therefore
make _sure_ that it can do so.


-- 
                                Michael van Elst
Internet: mlelstv@serpens.de
                                "A potential Snark may lurk in every tree."