From: Waiman Long <longman@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Jonathan Corbet <corbet@lwn.net>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-doc@vger.kernel.org,
"Luis R. Rodriguez" <mcgrof@kernel.org>,
Kees Cook <keescook@chromium.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Jan Kara <jack@suse.cz>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>,
Miklos Szeredi <mszeredi@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Larry Woodman <lwoodman@redhat.com>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
"Wangkai (Kevin C)" <wangkai86@huawei.com>,
Michal Hocko <mhocko@kernel.org>
Subject: Re: [PATCH 1/2] fs/dcache: Track & report number of negative dentries
Date: Thu, 30 Aug 2018 17:49:43 -0400 [thread overview]
Message-ID: <93a9aa18-20ea-db99-6732-d43298cec3fc@redhat.com> (raw)
In-Reply-To: <20180830014304.GD5631@dastard>
On 08/29/2018 09:43 PM, Dave Chinner wrote:
> On Wed, Aug 29, 2018 at 01:11:08PM -0400, Waiman Long wrote:
>> On 08/28/2018 08:11 PM, Dave Chinner wrote:
>>> On Tue, Aug 28, 2018 at 01:19:39PM -0400, Waiman Long wrote:
>>>> The current dentry number tracking code doesn't distinguish between
>>>> positive & negative dentries. It just reports the total number of
>>>> dentries in the LRU lists.
>>>>
>>>> As excessive number of negative dentries can have an impact on system
>>>> performance, it will be wise to track the number of positive and
>>>> negative dentries separately.
>>>>
>>>> This patch adds tracking for the total number of negative dentries in
>>>> the system LRU lists and reports it in the /proc/sys/fs/dentry-state
>>>> file. The number, however, does not include negative dentries that are
>>>> in flight but not in the LRU yet.
>>>>
>>>> The number of positive dentries in the LRU lists can be roughly found
>>>> by subtracting the number of negative dentries from the total.
>>>>
>>>> Signed-off-by: Waiman Long <longman@redhat.com>
>>>> ---
>>>> Documentation/sysctl/fs.txt | 19 +++++++++++++------
>>>> fs/dcache.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
>>>> include/linux/dcache.h | 7 ++++---
>>>> 3 files changed, 62 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt
>>>> index 819caf8..118bb93 100644
>>>> --- a/Documentation/sysctl/fs.txt
>>>> +++ b/Documentation/sysctl/fs.txt
>>>> @@ -63,19 +63,26 @@ struct {
>>>> int nr_unused;
>>>> int age_limit; /* age in seconds */
>>>> int want_pages; /* pages requested by system */
>>>> - int dummy[2];
>>>> + int nr_negative; /* # of unused negative dentries */
>>>> + int dummy;
>>>> } dentry_stat = {0, 0, 45, 0,};
>>> That's not a backwards compatible ABI change. Those dummy fields
>>> used to represent some metric we no longer calculate, and there are
>>> probably still monitoring apps out there that think they still have
>>> the old meaning. i.e. they are still visible to userspace:
>>>
>>> $ cat /proc/sys/fs/dentry-state
>>> 83090 67661 45 0 0 0
>>> $
>>>
>>> IOWs, you can add new fields for new metrics to the end of the
>>> structure, but you can't re-use existing fields even if they
>>> aren't calculated anymore.
>>>
>>> [....]
>> I looked up the git history and the state of the dentry_stat structure
>> hadn't changed since it was first put into git in 2.6.12-rc2 on Apr 16,
>> 2005. That was over 13 years ago. Even adding an extra argument can have
>> the potential of breaking old applications depending on how the parsing
>> code was written.
> I'm pretty we've had this discussion many times before w.r.t.
> /proc/self/mount* and other multi-field proc files.
>
> IIRC, The answer has always been that it's OK to extend lines with
> new fields as existing apps /should/ ignore them, but it's not OK to
> remove or redefine existing fields in the line because existing apps
> /will/ misinterpret what that field means.
>
>> Given that systems that are still using some very old tools are not
>> likely to upgrade to the latest kernel anyway. I don't see that as a big
>> problem.
> I don't think that matters when it comes to changing what
> information we expose in proc files.
>
> Cheers,
>
> Dave.
I am not against appending the new count to the end. I just want to make
sure that it is the right thing to do.
Cheers,
Longman
next prev parent reply other threads:[~2018-08-30 21:49 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-28 17:19 [PATCH 0/2] fs/dcache: Track # of negative dentries Waiman Long
2018-08-28 17:19 ` [PATCH 1/2] fs/dcache: Track & report number " Waiman Long
2018-08-29 0:11 ` Dave Chinner
2018-08-29 17:11 ` Waiman Long
2018-08-30 1:43 ` Dave Chinner
2018-08-30 21:49 ` Waiman Long [this message]
2018-08-31 14:31 ` Matthew Wilcox
2018-08-31 15:03 ` Waiman Long
2018-08-28 17:19 ` [PATCH 2/2] fs/dcache: Make negative dentries easier to be reclaimed Waiman Long
2018-08-28 22:13 ` Matthew Wilcox
2018-08-28 22:29 ` Waiman Long
2018-08-28 23:10 ` Linus Torvalds
2018-08-28 23:22 ` Andrew Morton
2018-08-29 1:18 ` Waiman Long
2018-08-29 1:18 ` Waiman Long
2018-08-28 23:01 ` Andrew Morton
2018-08-29 17:54 ` Paul E. McKenney
2018-08-29 20:03 ` Waiman Long
2018-08-29 21:04 ` Matthew Wilcox
2018-08-29 1:02 ` Dave Chinner
2018-08-29 19:34 ` Waiman Long
2018-08-30 1:12 ` Dave Chinner
2018-08-30 21:51 ` Waiman Long
2018-08-29 7:51 ` Michal Hocko
2018-08-29 19:58 ` Waiman Long
2018-08-30 7:20 ` Michal Hocko
2018-08-30 21:48 ` Waiman Long
2018-08-28 22:50 ` [PATCH 0/2] fs/dcache: Track # of negative dentries Andrew Morton
2018-08-28 22:54 ` 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=93a9aa18-20ea-db99-6732-d43298cec3fc@redhat.com \
--to=longman@redhat.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=keescook@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lwoodman@redhat.com \
--cc=mcgrof@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).