linux-kernel - Re: [PATCH v6 0/7] fs/dcache: Track & limit # of negative dentries

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: <1531425435.18255.17.camel@HansenPartnership.com>
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