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: Thu, 12 Jul 2018 12:57:15 -0700 From: James Bottomley <James.Bottomley@...senPartnership.com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Matthew Wilcox <willy@...radead.org>, Waiman Long <longman@...hat.com>, Michal Hocko <mhocko@...nel.org>, Al Viro <viro@...iv.linux.org.uk>, Jonathan Corbet <corbet@....net>, "Luis R. Rodriguez" <mcgrof@...nel.org>, Kees Cook <keescook@...omium.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, linux-mm <linux-mm@...ck.org>, "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>, Jan Kara <jack@...e.cz>, Paul McKenney <paulmck@...ux.vnet.ibm.com>, Andrew Morton <akpm@...ux-foundation.org>, Ingo Molnar <mingo@...nel.org>, Miklos Szeredi <mszeredi@...hat.com>, Larry Woodman <lwoodman@...hat.com>, "Wangkai (Kevin,C)" <wangkai86@...wei.com> Subject: Re: [PATCH v6 0/7] fs/dcache: Track & limit # of negative dentries On Thu, 2018-07-12 at 11:06 -0700, Linus Torvalds wrote: > On Thu, Jul 12, 2018 at 10:21 AM James Bottomley > <James.Bottomley@...senpartnership.com> wrote: > > > > On Thu, 2018-07-12 at 09:49 -0700, Matthew Wilcox wrote: > > > > > > I don't know that it does work. Or that it works well. > > > > I'm not claiming the general heuristics are perfect (in fact I know > > we > > still have a lot of problems with dirty reclaim and writeback). > > I think this whole "this is about running out of memory" approach is > wrong. > > We *should* handle that well. Or well enough in practice, at least. > > Do we? Maybe not. Should the dcache be the one area to be policed and > worked around? Probably not. > > But there may be other reasons to just limit negative dentries. > > What does the attached program do to people? It's written to be > intentionally annoying to the dcache. So it's interesting. What happens for me is that I start out at pretty much no free memory so the programme slowly starts to fill up my available swap without shrinking my page cache (presumably it's causing dirty anonymous objects to be pushed out) and the dcache grows a bit. Then when my free swap reaches 0 we start to reclaim the dcache and it shrinks again (apparently still keeping the page cache at around 1.8G). The system seems perfectly usable while this is running (tried browser and a couple of compiles) ... any calls for free memory seem to come out of the enormous but easily reclaimable dcache. The swap effect is unexpected, but everything else seems to be going according to how I would wish. When I kill the programme I get about a megabyte of swap back but it's staying with the rest of swap occupied. When all this started I had an 8G laptop with 2G of swap of which 1G was used. Now I have 2G of swap used but it all seems to be running OK. So what I mean by dcache grows a bit is this: I missed checking it before I started, but it eventually grew to jejb@...vis:~> cat /proc/sys/fs/dentry-state 2841534 2816297 45 0 0 0 Before eventually going back after I killed the programme to jejb@...vis:~> cat /proc/sys/fs/dentry-state 806559 781138 45 0 0 0 I just tried it again and this time the dcache only peaked at jejb@...vis:~> cat /proc/sys/fs/dentry-state 2321933 2296607 45 0 0 0 What surprises me most about this behaviour is the steadiness of the page cache ... I would have thought we'd have shrunk it somewhat given the intense call on the dcache. James
Powered by blists - more mailing lists