Re: Copying to loop device hangs up everything

[Andrew Morton <akpm@zip.com.au>]

Andrea Arcangeli wrote:
> 
> ...
> > The thing I don't like about the Andrea+Momchil approach is that it
> > exposes the risk of flooding the machine with dirty data.  A scheme
> 
> it doesn't, balance_dirty() has to work only  at the highlevel.
> sync_page_buffers also is no problem, we'll try again later in those
> GFP_NOIO allocations.

Not so.  The loop thread *copies* the data.  We must throttle it,
otherwise the loop thread gobbles all memory and the box dies.  This
is trivial to demonstrate.

> furthmore you don't even address the writepage from loop thread on the
> loop queue.

How can this deadlock?  The only path to those buffers is
via the page, and the page is locked.
 
> The final fix should be in rc2aa1 that I will release in a jiffy. It
> takes care now of both the VM and balance_dirty().
>
> this is the incremental fix against rc1aa1:
> 

No.  Your patch removes *all* loop thread throttling, it doesn't even start
IO (thus removing the throttling which request starving would provide)
and doesn't even wake up bdflush.

If you set nfract to 70%, nfract_sync to 80% and do a big write, the
machine falls into a VM coma within 15 seconds.  The same happens
with both my patches :-(

And it's not legitimate to say "don't do that".  If we can't survive
those settings, we don't have a solution. We need to throttle writes
*more*, not less.

I'll keep poking at it.   If you have any more suggestions/patches,
please toss them over...

-