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: Wed, 24 Jan 2007 08:55:33 +0100 From: Peter Zijlstra <a.p.zijlstra@...llo.nl> To: Christoph Lameter <clameter@....com> Cc: Aubrey Li <aubreylee@...il.com>, Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>, Nick Piggin <nickpiggin@...oo.com.au>, Robin Getz <rgetz@...ckfin.uclinux.org>, "Henn, erich, Michael" <Michael.Hennerich@...log.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org Subject: Re: [RFC] Limit the size of the pagecache On Tue, 2007-01-23 at 16:49 -0800, Christoph Lameter wrote: > This is a patch using some of Aubrey's work plugging it in what is IMHO > the right way. Feel free to improve on it. I have gotten repeatedly > requests to be able to limit the pagecache. With the revised VM statistics > this is now actually possile. I'd like to know more about possible uses of > such a feature. > > > > > It may be useful to limit the size of the page cache for various reasons > such as > > 1. Insure that anonymous pages that may contain performance > critical data is never subject to swap. This is what we have mlock for, no? > 2. Insure rapid turnaround of pages in the cache. This sounds like we either need more fadvise hints and/or understand why the VM doesn't behave properly. > 3. Reserve memory for other uses? (Aubrey?) He wants to make a nommu system act like a mmu system; this will just never ever work. Memory fragmentation is a real issue not some gimmick thought up by the hardware folks to sell these mmu chips. > We add a new variable "pagecache_ratio" to /proc/sys/vm/ that > defaults to 100 (all memory usable for the pagecache). > > The size of the pagecache is the number of file backed > pages in a zone which is available through NR_FILE_PAGES. > > We skip zones that contain too many page cache pages in > the page allocator which may cause us to enter reclaim. > > If we enter reclaim and the number of page cache pages > is too high then we switch off swapping during reclaim > to avoid touching anonymous pages. > > Signed-off-by: Christoph Lameter <clameter@....com> Code looks nice, however earlier responses have raised good points. Esp. the one pointing out you'd need to defeat swappiness too. That said, I'm not much in favour of a limit pagecache knob. Esp. the "my customers are scared of the 99.9% memory used scenario" is a clear case of educate them. We don't go fix psychological problems with code. The only maybe valid point would be 2, and I'd like to see if we can't solve that differently - a better use-once logic comes to mind. - 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