>  >  ok, then i think i understand the problem.
>  >  we should throttle activities creating dirty buffers.
>  >  maybe by having a flag for getblk and friends to tell
>  >  "we are not going to dirty the buffer".
>  
>  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?

>  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.

>  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 SoC-Project that adds congestion control to filesystems might
>  eventually address this problem correctly.

the device speed doesn't matter much here.
once you fill buffer cache with dirty data, you lose.

(i don't know what the soc-project is about.)

>  >  what your patch does is the opposite.  ie. throttling attempts of
>  >  cleaning buffers.  i believe it makes the situation worse.
>  
>  The patch does not throttle attempts of cleaning buffers. The
>  bottleneck for cleaning buffers is still the underlying filesystem
>  where the virtual device file resides.
>  
>  With the patch when vnd throttles the writer it does two things:
> 
>  it prevents it from generating more dirty buffers and
>  
>  it delays the requeuing of dirty buffers _when the underlying
>     filesystem is too slow to process them_.

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

YAMAMOTO Takashi