Re: [PATCH] Re: MM deadlock [was: Re: arca-vm-8...]

Andrea Arcangeli
1999-01-13T19:09:58Z

On Wed, 13 Jan 1999, Stephen C. Tweedie wrote:

> I think this is the wrong solution: far better to do the patch below,
> which simply exempts reads from nr_async_pages altogether. I
> originally added nr_async_pages to serve two functions: to allow
> kswapd to determine how much memory it was already in the process of
> freeing, and to act as a throttle on the number of write IOs submitted
> when swapping.
>
> We don't need a similar throttling action for reads, because every
> place where we do VM readahead, each readahead IO cluster is followed
> by a synchronous read on one page. We don't throttle the async
> readaheads on normal file IO, for example.

Note that we don't need nr_async_pages at all. Here when the limit of
nr_async_pages is low it's only a bottleneck for swapout performances. I
have not removed it (because it could be useful to decrease swapout I/O if
somebody needs this strange feature), but I have added a
page_daemon.max_async_pages and set it to something like 256. Now I check
nr_async_pages against the new max_async_pages.

I _guess_ (not checked) that the _only_ reason Steve seen arca-vm-16 so
high improved changing SWAP_CLUSTER_MAX to 512 instead of 32 is the
removal of the nr_async_pages bottleneck.

Andrea Arcangeli