From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763028AbXG1LQd (ORCPT ); Sat, 28 Jul 2007 07:16:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755232AbXG1LQ0 (ORCPT ); Sat, 28 Jul 2007 07:16:26 -0400 Received: from outpipe-village-512-1.bc.nu ([81.2.110.250]:45528 "EHLO the-village.bc.nu" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1755250AbXG1LQZ (ORCPT ); Sat, 28 Jul 2007 07:16:25 -0400 Date: Sat, 28 Jul 2007 12:21:39 +0100 From: Alan Cox To: Rene Herman Cc: david@lang.hm, Daniel Hazelton , Mike Galbraith , Andrew Morton , Ingo Molnar , Frank Kingswood , Andi Kleen , Nick Piggin , Ray Lee , Jesper Juhl , ck list , Paul Jackson , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23] Message-ID: <20070728122139.3c7f4290@the-village.bc.nu> In-Reply-To: <46AB166A.2000300@gmail.com> References: <9a8748490707231608h453eefffx68b9c391897aba70@mail.gmail.com> <20070727030040.0ea97ff7.akpm@linux-foundation.org> <1185531918.8799.17.camel@Homer.simpson.net> <200707271345.55187.dhazelton@enter.net> <46AA3680.4010508@gmail.com> <46AAEDEB.7040003@gmail.com> <46AB166A.2000300@gmail.com> X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.13; i386-redhat-linux-gnu) Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > It is. Prefetched pages can be dropped on the floor without additional I/O. Which is essentially free for most cases. In addition your disk access may well have been in idle time (and should be for this sort of stuff) and if it was in the same chunk as something nearby was effectively free anyway. Actual physical disk ops are precious resource and anything that mostly reduces the number will be a win - not to stay swap prefetch is the right answer but accidentally or otherwise there are good reasons it may happen to help. Bigger more linear chunks of writeout/readin is much more important I suspect than swap prefetching. > good overview of exactly how broken -mm can be at times. How many -mm users > use it anyway? He himself said he's not convinced of usefulness having not I've been using it for months with no noticed problem. I turn it on because it might as well get tested. I've not done comparison tests so I can't comment on if its worth it. Lots of -mm testers turn *everything* on because its a test kernel.