From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Jan Kara <jack@suse.cz>,
Paul McKenney <paulmck@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Miklos Szeredi <mszeredi@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Larry Woodman <lwoodman@redhat.com>,
"Wangkai (Kevin,C)" <wangkai86@huawei.com>,
linux-mm@kvack.org, Michal Hocko <mhocko@kernel.org>
Subject: Re: [PATCH v5 0/6] fs/dcache: Track & limit # of negative dentries
Date: Mon, 02 Jul 2018 15:34:40 -0700 [thread overview]
Message-ID: <1530570880.3179.9.camel@HansenPartnership.com> (raw)
In-Reply-To: <20180702141811.ef027fd7d8087b7fb2ba0cce@linux-foundation.org>
On Mon, 2018-07-02 at 14:18 -0700, Andrew Morton wrote:
> On Mon, 2 Jul 2018 12:34:00 -0700 Linus Torvalds <torvalds@linux-foun
> dation.org> wrote:
>
> > On Sun, Jul 1, 2018 at 10:52 PM Waiman Long <longman@redhat.com>
> > wrote:
> > >
> > > A rogue application can potentially create a large number of
> > > negative
> > > dentries in the system consuming most of the memory available if
> > > it
> > > is not under the direct control of a memory controller that
> > > enforce
> > > kernel memory limit.
> >
> > I certainly don't mind the patch series, but I would like it to be
> > accompanied with some actual example numbers, just to make it all a
> > bit more concrete.
> >
> > Maybe even performance numbers showing "look, I've filled the
> > dentry
> > lists with nasty negative dentries, now it's all slower because we
> > walk those less interesting entries".
> >
>
> (Please cc linux-mm@kvack.org on this work)
>
> Yup. The description of the user-visible impact of current behavior
> is far too vague.
>
> In the [5/6] changelog it is mentioned that a large number of -ve
> dentries can lead to oom-killings. This sounds bad - -ve dentries
> should be trivially reclaimable and we shouldn't be oom-killing in
> such a situation.
If you're old enough, it's déjà vu; Andrea went on a negative dentry
rampage about 15 years ago:
https://lkml.org/lkml/2002/5/24/71
I think the summary of the thread is that it's not worth it because
dentries are a clean cache, so they're immediately shrinkable.
> Dumb question: do we know that negative dentries are actually
> worthwhile? Has anyone checked in the past couple of
> decades? Perhaps our lookups are so whizzy nowadays that we don't
> need them?
There are still a lot of applications that keep looking up non-existent
files, so I think it's still beneficial to keep them. Apparently
apache still looks for a .htaccess file in every directory it
traverses, for instance. Round tripping every one of these to disk
instead of caching it as a negative dentry would seem to be a
performance loser here.
However, actually measuring this again might be useful.
James
WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Jan Kara <jack@suse.cz>,
Paul McKenney <paulmck@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Miklos Szeredi <mszeredi@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Larry Woodman <lwoodman@redhat.com>,
"Wangkai (Kevin,C)" <wangkai86@huawei.com>,
linux-mm@kvack.org, Michal Hocko <mhocko@kernel.org>
Subject: Re: [PATCH v5 0/6] fs/dcache: Track & limit # of negative dentries
Date: Mon, 02 Jul 2018 15:34:40 -0700 [thread overview]
Message-ID: <1530570880.3179.9.camel@HansenPartnership.com> (raw)
In-Reply-To: <20180702141811.ef027fd7d8087b7fb2ba0cce@linux-foundation.org>
On Mon, 2018-07-02 at 14:18 -0700, Andrew Morton wrote:
> On Mon, 2 Jul 2018 12:34:00 -0700 Linus Torvalds <torvalds@linux-foun
> dation.org> wrote:
>
> > On Sun, Jul 1, 2018 at 10:52 PM Waiman Long <longman@redhat.com>
> > wrote:
> > >
> > > A rogue application can potentially create a large number of
> > > negative
> > > dentries in the system consuming most of the memory available if
> > > it
> > > is not under the direct control of a memory controller that
> > > enforce
> > > kernel memory limit.
> >
> > I certainly don't mind the patch series, but I would like it to be
> > accompanied with some actual example numbers, just to make it all a
> > bit more concrete.
> >
> > Maybe even performance numbers showing "look, I've filled the
> > dentry
> > lists with nasty negative dentries, now it's all slower because we
> > walk those less interesting entries".
> >
>
> (Please cc linux-mm@kvack.org on this work)
>
> Yup.A A The description of the user-visible impact of current behavior
> is far too vague.
>
> In the [5/6] changelog it is mentioned that a large number of -ve
> dentries can lead to oom-killings.A A This sounds bad - -ve dentries
> should be trivially reclaimable and we shouldn't be oom-killing in
> such a situation.
If you're old enough, it's dA(C)jA vu; Andrea went on a negative dentry
rampage about 15 years ago:
https://lkml.org/lkml/2002/5/24/71
I think the summary of the thread is that it's not worth it because
dentries are a clean cache, so they're immediately shrinkable.
> Dumb question: do we know that negative dentries are actually
> worthwhile?A A Has anyone checked in the past couple of
> decades?A A Perhaps our lookups are so whizzy nowadays that we don't
> need them?
There are still a lot of applications that keep looking up non-existent
files, so I think it's still beneficial to keep them. Apparently
apache still looks for a .htaccess file in every directory it
traverses, for instance. Round tripping every one of these to disk
instead of caching it as a negative dentry would seem to be a
performance loser here.
However, actually measuring this again might be useful.
James
next prev parent reply other threads:[~2018-07-02 22:34 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-02 5:51 [PATCH v5 0/6] fs/dcache: Track & limit # of negative dentries Waiman Long
2018-07-02 5:51 ` [PATCH v5 1/6] fs/dcache: Track & report number " Waiman Long
2018-07-02 5:51 ` [PATCH v5 2/6] fs/dcache: Make negative dentry tracking configurable Waiman Long
2018-07-02 21:12 ` Andrew Morton
2018-07-03 0:59 ` Waiman Long
2018-07-02 5:52 ` [PATCH v5 3/6] fs/dcache: Enable automatic pruning of negative dentries Waiman Long
2018-07-02 5:52 ` [PATCH v5 4/6] fs/dcache: Spread negative dentry pruning across multiple CPUs Waiman Long
2018-07-02 5:52 ` [PATCH v5 5/6] fs/dcache: Allow optional enforcement of negative dentry limit Waiman Long
2018-07-02 5:52 ` [PATCH v5 6/6] fs/dcache: Make negative dentry limit enforcement sysctl parameter Waiman Long
2018-07-02 19:34 ` [PATCH v5 0/6] fs/dcache: Track & limit # of negative dentries Linus Torvalds
2018-07-02 21:18 ` Andrew Morton
2018-07-02 22:21 ` Matthew Wilcox
2018-07-02 22:31 ` Linus Torvalds
2018-07-02 22:34 ` James Bottomley [this message]
2018-07-02 22:34 ` James Bottomley
2018-07-02 22:54 ` Linus Torvalds
2018-07-02 23:03 ` Linus Torvalds
2018-07-02 23:19 ` Andrew Morton
2018-07-02 23:28 ` Linus Torvalds
2018-07-03 1:38 ` Waiman Long
2018-07-03 9:18 ` Jan Kara
2018-07-03 9:18 ` Jan Kara
2018-07-03 9:18 ` Jan Kara
2018-07-14 17:35 ` Pavel Machek
2018-07-14 18:00 ` Linus Torvalds
2018-07-14 18:34 ` Al Viro
2018-07-14 18:36 ` Al Viro
2018-07-14 18:43 ` Linus Torvalds
2018-07-18 16:01 ` Waiman Long
2018-07-03 1:11 ` Waiman Long
2018-07-03 13:48 ` Vlastimil Babka
2018-07-03 0:46 ` Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1530570880.3179.9.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=lwoodman@redhat.com \
--cc=mhocko@kernel.org \
--cc=mingo@kernel.org \
--cc=mszeredi@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=wangkai86@huawei.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.