Re: Copying to loop device hangs up everything

Andrew Morton
2001-12-20T07:44:00Z

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

-