linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Waiman Long <longman@redhat.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>
Subject: Re: [PATCH 2/2] fs/dcache: Make negative dentries easier to be reclaimed
Date: Wed, 29 Aug 2018 09:51:29 +0200	[thread overview]
Message-ID: <20180829075129.GU10223@dhcp22.suse.cz> (raw)
In-Reply-To: <1535476780-5773-3-git-send-email-longman@redhat.com>

On Tue 28-08-18 13:19:40, Waiman Long wrote:
> For negative dentries that are accessed once and never used again, they
> should be removed first before other dentries when shrinker is running.
> This is done by putting negative dentries at the head of the LRU list
> instead at the tail.
> 
> A new DCACHE_NEW_NEGATIVE flag is now added to a negative dentry when it
> is initially created. When such a dentry is added to the LRU, it will be
> added to the head so that it will be the first to go when a shrinker is
> running if it is never accessed again (DCACHE_REFERENCED bit not set).
> The flag is cleared after the LRU list addition.

Placing object to the head of the LRU list can be really tricky as Dave
pointed out. I am not familiar with the dentry cache reclaim so my
comparison below might not apply. Let me try anyway.

Negative dentries sound very similar to MADV_FREE pages from the reclaim
POV. They are primary candidate for reclaim, yet you want to preserve
aging to other easily reclaimable objects (including other MADV_FREE
pages). What we do for those pages is to move them from the anonymous
LRU list to the inactive file LRU list. Now you obviously do not have
anon/file LRUs but something similar to active/inactive LRU lists might
be a reasonably good match. Have easily reclaimable dentries on the
inactive list including negative dentries. If negative entries are
heavily used then they can promote to the active list because there is
no reason to reclaim them soon.

Just my 2c
-- 
Michal Hocko
SUSE Labs

  parent reply	other threads:[~2018-08-29  7:51 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
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 [this message]
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=20180829075129.GU10223@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --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=longman@redhat.com \
    --cc=lwoodman@redhat.com \
    --cc=mcgrof@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).