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
| ||
|
Date: Sat, 20 Jan 2007 13:24:45 +1100 From: Nick Piggin <nickpiggin@...oo.com.au> To: Aubrey Li <aubreylee@...il.com> CC: Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>, linux-kernel@...r.kernel.org, linux-mm@...ck.org, Linus Torvalds <torvalds@...l.org>, Andrew Morton <akpm@...l.org>, "linux-os (Dick Johnson)" <linux-os@...logic.com>, Robin Getz <rgetz@...ckfin.uclinux.org>, "Hennerich, Michael" <Michael.Hennerich@...log.com> Subject: Re: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache Aubrey Li wrote: > On 1/20/07, Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com> wrote: >> If pagecache is overlimit, we expect old (cold) pagecache pages to >> be thrown out and reused for new file data. We do not expect to >> drop a few text or data pages to make room for new pagecache. >> > Well, actually I think this probably not necessary. Because the > reclaimer has no way to predict the behavior of user mode processes, > how do you make sure the pagecache will not be access again in a short It is not about predicting behaviour, it is about directing the reclaim effort at the actual resource that is under pressure. Even given a pagecache limiting patch which does the proper accounting to keep pagecache pages under a % limit (unlike yours), kicking off an undirected reclaim could (in theory) reclaim all slab and anonymous memory pages before bringing pagecache under the limit. So I think you need to be a bit more thorough than just assuming everything will be OK. Page reclaim behaviour is pretty strange and complex. Secondly, your patch isn't actually very good. It unconditionally shrinks memory to below the given % mark each time a pagecache alloc occurs, regardless of how much pagecache is in the system. Effectively that seems to just reduce the amount of memory available to the system. Luckily, there are actually good, robust solutions for your higher order allocation problem. Do higher order allocations at boot time, modifiy userspace applications, or set up otherwise-unused, or easily reclaimable reserve pools for higher order allocations. I don't understand why you are so resistant to all of these approaches? -- 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/
Powered by blists - more mailing lists