Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965644AbXAXDvl (ORCPT ); Tue, 23 Jan 2007 22:51:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965646AbXAXDvl (ORCPT ); Tue, 23 Jan 2007 22:51:41 -0500 Received: from wx-out-0506.google.com ([66.249.82.227]:61915 "EHLO wx-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965644AbXAXDvk (ORCPT ); Tue, 23 Jan 2007 22:51:40 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bZP7MpNoJLwILoVJa6HIdnOCp+uV2xnj2qaUfhPj5NDdpYQrM5xGSkmK6I+cADx/7SYJ/OH5qfkkVc9MORx7HL8ECWrf3ehBSJKOLWhKRwmwPsnWYIrsk1AXSK/JBh/MTJdLC4OhqT4mB6hxqazD5N2LzZZTZAO3DIJefUKto94= Message-ID: <6d6a94c50701231951o66487813vcd078fc25e25ffa0@mail.gmail.com> Date: Wed, 24 Jan 2007 11:51:39 +0800 From: "Aubrey Li" To: "Christoph Lameter" Subject: Re: [RFC] Limit the size of the pagecache Cc: "Nick Piggin" , "Vaidyanathan Srinivasan" , "Robin Getz" , "Hennerich, Michael" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, dgc@sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B6CBD9.80600@yahoo.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2770 Lines: 68 On 1/24/07, Christoph Lameter wrote: > On Wed, 24 Jan 2007, Nick Piggin wrote: > > > > 1. Insure that anonymous pages that may contain performance > > > critical data is never subject to swap. > > > > > > 2. Insure rapid turnaround of pages in the cache. > > > > So if these two aren't working properly at 100%, then I want to know the > > reason why. Or at least see what the workload and the numbers look like. > > The reason for the anonymous page may be because data is rarely touched > but for some reason the pages must stay in memory. Rapid turnaround is > just one of the reason that I vaguely recall but I never really > understood what the purpose was. > > > > 3. Reserve memory for other uses? (Aubrey?) > > > > Maybe. This is still a bad hack, and I don't like to legitimise such use > > though. I hope Aubrey isn't relying on this alone for his device to work > > because his customers might end up hitting fragmentation problems sooner > > or later. > > I surely wish that Aubrey would give us some more clarity on > how this should work. Maybe the others who want this feature could also > speak up? I am not that clear on its purpose. > Sorry for the delay. Somehow this thread was put into the spam folder of my gmail box. :( The patch I posted several days ago works properly on my side. I'm working on blackfin-uclinux platform. So I'm not sure it works 100% on the other arch platform. From O_DIRECT threads, I know different people suffer from VFS pagecache issue for different reason. So I really hope the patch can be improved. On my side, When VFS pagecache eat up all of the available memory, applications who want to allocate the largeish block(order =4 ?) will fail. So the logic is as follows: if request pagecache watermark = min + reserved_pagecache. else watermark = min. Here, assume min=123 pages, reserved_pagecache = 200 pages. That means when VFS pagecache eat up its all of available memory, there are still 200 pages available for the allocation of the application. Does that make sense? > I hope Aubrey isn't relying on this alone for his device to work > because his customers might end up hitting fragmentation problems sooner > or later. That's true. I wrote a replacement of buddy system, it's here: http://lkml.org/lkml/2006/12/30/36. That can improve the fragmentation problems on our platform. Christoph - I can't find your original patch, Can you send me again? it would be great if you merged all of the enhancement. Thanks, -Aubrey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/