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 RAA20801 for ; Wed, 13 Jan 1999 17:12:11 -0500 Date: Wed, 13 Jan 1999 22:11:47 GMT Message-Id: <199901132211.WAA07405@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: MM deadlock [was: Re: arca-vm-8...] In-Reply-To: References: Sender: owner-linux-mm@kvack.org To: Andrea Arcangeli Cc: Chris Evans , Rik van Riel , Zlatko Calusic , Linus Torvalds , "Stephen C. Tweedie" , "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 16:07:13 +0100 (CET), Andrea Arcangeli said: > On Wed, 13 Jan 1999, Chris Evans wrote: >> Yes. Imagine the paging in of big binary case. The page faults will occur >> all over the place, not in a nice sequential order. The page-in clusters >> stuff _doubled_ performance of paging in certain big static binaries. > I think that if it helped it means that the swap cache got shrunk too much > early due a not good free paging algorithm. Not in the slightest. We're talking about the things like the performance of starting up a fresh new copy of netscape. Swapout has nothing to do with it in that case: we are starting from a ground state where the binary is completely uncached. The clustered pagein has a huge impact in that case. --Stephen -- This is a majordomo managed list. To unsubscribe, send a message with the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org