Messages in this thread | | | Date | Wed, 24 Jan 2007 11:51:39 +0800 | From | "Aubrey Li" <> | Subject | Re: [RFC] Limit the size of the pagecache |
| |
On 1/24/07, Christoph Lameter <clameter@sgi.com> 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/
| |