Re: Comment on patch to remove nr_async_pages limitA

[Mike Galbraith <mikeg@wen-online.de>]

On Tue, 5 Jun 2001, Benjamin C.R. LaHaise wrote:

> On Tue, 5 Jun 2001, Mike Galbraith wrote:
>
> > Yes.  If we start writing out sooner, we aren't stuck with pushing a
> > ton of IO all at once and can use prudent limits.  Not only because of
> > potential allocation problems, but because our situation is changing
> > rapidly so small corrections done often is more precise than whopping
> > big ones can be.
>
> Hold on there big boy, writing out sooner is not better.  What if the

(do definitely beat my thoughts up, please don't use condescending terms)

In some cases, it definitely is.  I can routinely improve throughput
by writing more.. that is a measurable and reproducable fact.  I know
also from measurement that it is not _always_ the right thing to do.

> memory shortage is because real data is being written out to disk?

(I would hope that we're doing our best to always be writing real data
to disk.  I also know that this isn't always the case.)

> Swapping early causes many more problems than swapping late as extraneous
> seeks to the swap partiton severely degrade performance.

That is not the case here at the spot in the performance curve I'm
looking at (transition to throughput).

Does this mean the block layer and/or elevator is having problems?  Why
would using avaliable disk bandwidth vs letting it lie dormant be a
generically bad thing?.. this I just can't understand.  The elevator
deals with seeks, the vm is flat not equipped to do so.. it contains
such concept.

Avoiding write is great, delaying write is not at _all_ great.

	-Mike

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/