From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dax.scot.redhat.com (sct@dax.scot.redhat.com [195.89.149.242]) by kvack.org (8.8.7/8.8.7) with ESMTP id RAA20770 for ; Wed, 13 Jan 1999 17:10:40 -0500 Date: Wed, 13 Jan 1999 22:10:12 GMT Message-Id: <199901132210.WAA07391@dax.scot.redhat.com> From: "Stephen C. Tweedie" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PATCH] Re: MM deadlock [was: Re: arca-vm-8...] In-Reply-To: References: <199901131755.RAA06476@dax.scot.redhat.com> Sender: owner-linux-mm@kvack.org To: Andrea Arcangeli Cc: "Stephen C. Tweedie" , Linus Torvalds , Rik van Riel , Zlatko Calusic , "Eric W. Biederman" , Savochkin Andrey Vladimirovich , steve@netplus.net, brent verner , "Garst R. Reese" , Kalle Andersson , Ben McCann , Alan Cox , bredelin@ucsd.edu, linux-kernel@vger.rutgers.edu, linux-mm@kvack.org List-ID: Hi, On Wed, 13 Jan 1999 19:52:03 +0100 (CET), Andrea Arcangeli said: > 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. The problem is that if you do this, it is easy for the swapper to generate huge amounts of async IO without actually freeing any real memory: there's a question of balancing the amount of free memory we have available right now with the amount which we are in the process of freeing. Setting the nr_async_pages bound to 256 just makes the swapper keen to send a whole 1MB of memory out to disk at a time, which is a bit steep on an 8MB box. --Stephen -- This is a majordomo managed list. To unsubscribe, send a message with the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org