linux-kernel - Re: [RFC] Limit the size of the pagecache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45B6DA8B.7060004@yahoo.com.au>
Date:	Wed, 24 Jan 2007 15:03:23 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Aubrey Li <aubreylee@...il.com>
CC:	Christoph Lameter <clameter@....com>,
	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
	Robin Getz <rgetz@...ckfin.uclinux.org>,
	"Hennerich, Michael" <Michael.Hennerich@...log.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, dgc@....com
Subject: Re: [RFC] Limit the size of the pagecache

Aubrey Li wrote:
> On 1/24/07, Christoph Lameter <clameter@....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.

So we need to work out what those issues are and fix them.

> 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:

Yeah, it will be failing at order=4, because the allocator won't try
very hard reclaim pagecache pages at that cutoff point. This needs to
be fixed in the allocator.

>> 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.

That might be a good idea, but while the buddy system may not seem as
efficient and wastes space, it is actually really good for fragmentation.

Anyway, point being that you can't eliminate fragmentation, so you need
to cope with allocation failures or implement reserve pools if you want a
robust system.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/