From: Johannes Weiner <hannes@cmpxchg.org>
To: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@fb.com
Subject: Re: [PATCH 5/6] mm: workingset: switch shadow entry tracking to radix tree exceptional counting
Date: Tue, 8 Nov 2016 14:30:11 -0500 [thread overview]
Message-ID: <20161108193011.GA15802@cmpxchg.org> (raw)
In-Reply-To: <20161108102716.GL32353@quack2.suse.cz>
On Tue, Nov 08, 2016 at 11:27:16AM +0100, Jan Kara wrote:
> On Mon 07-11-16 14:07:40, Johannes Weiner wrote:
> > Currently, we track the shadow entries in the page cache in the upper
> > bits of the radix_tree_node->count, behind the back of the radix tree
> > implementation. Because the radix tree code has no awareness of them,
> > we rely on random subtleties throughout the implementation (such as
> > the node->count != 1 check in the shrinking code which is meant to
> > exclude multi-entry nodes, but also happens to skip nodes with only
> > one shadow entry since it's accounted in the upper bits). This is
> > error prone and has, in fact, caused the bug fixed in d3798ae8c6f3
> > ("mm: filemap: don't plant shadow entries without radix tree node").
> >
> > To remove these subtleties, this patch moves shadow entry tracking
> > from the upper bits of node->count to the existing counter for
> > exceptional entries. node->count goes back to being a simple counter
> > of valid entries in the tree node and can be shrunk to a single byte.
>
> ...
>
> > diff --git a/mm/truncate.c b/mm/truncate.c
> > index 6ae44571d4c7..d3ce5f261f47 100644
> > --- a/mm/truncate.c
> > +++ b/mm/truncate.c
> > @@ -53,7 +53,6 @@ static void clear_exceptional_entry(struct address_space *mapping,
> > mapping->nrexceptional--;
> > if (!node)
> > goto unlock;
> > - workingset_node_shadows_dec(node);
> > /*
> > * Don't track node without shadow entries.
> > *
> > @@ -61,8 +60,7 @@ static void clear_exceptional_entry(struct address_space *mapping,
> > * The list_empty() test is safe as node->private_list is
> > * protected by mapping->tree_lock.
> > */
> > - if (!workingset_node_shadows(node) &&
> > - !list_empty(&node->private_list))
> > + if (!node->exceptional && !list_empty(&node->private_list))
> > list_lru_del(&workingset_shadow_nodes,
> > &node->private_list);
> > __radix_tree_delete_node(&mapping->page_tree, node);
>
> Is this really correct now? The radix tree implementation can move a single
> exceptional entry at index 0 from a node into a direct pointer and free
> the node while it is still in the LRU list. Or am I missing something?
You're right. I missed that scenario.
> To fix this I'd prefer to just have a callback from radix tree code when it
> is freeing a node, rather that trying to second-guess its implementation in
> the page-cache code...
>
> Otherwise the patch looks good to me and I really like the simplification!
That's a good idea. I'll do away with __radix_tree_delete_node()
altogether and move not just the slot accounting but also the tree
shrinking and the maintenance callback into __radix_tree_replace().
The page cache can then simply do
__radix_tree_replace(&mapping->page_tree, node, slot, new,
workingset_node_update, mapping)
And workingset_node_update() gets called on every node that changes,
where it can track and untrack it depending on count & exceptional.
I'll give it some testing before posting it, but currently it's
include/linux/radix-tree.h | 4 +-
include/linux/swap.h | 1 -
lib/radix-tree.c | 212 ++++++++++++++++++++-----------------------
mm/filemap.c | 48 +---------
mm/truncate.c | 16 +---
mm/workingset.c | 31 +++++--
6 files changed, 134 insertions(+), 178 deletions(-)
on top of the simplifications of this patch 5/6.
Thanks for your input, Jan!
next prev parent reply other threads:[~2016-11-08 19:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-07 19:07 [PATCH 0/6] mm: workingset: radix tree subtleties & single-page file refaults Johannes Weiner
2016-11-07 19:07 ` [PATCH 1/6] mm: khugepaged: fix radix tree node leak in shmem collapse error path Johannes Weiner
2016-11-08 9:53 ` Jan Kara
2016-11-08 16:12 ` Johannes Weiner
2016-11-09 7:41 ` Jan Kara
2016-11-11 10:59 ` Kirill A. Shutemov
2016-11-11 12:22 ` Jan Kara
2016-11-11 16:37 ` Kirill A. Shutemov
2016-11-14 8:07 ` Jan Kara
2016-11-14 14:29 ` Kirill A. Shutemov
2016-11-14 15:52 ` Johannes Weiner
2016-11-14 16:48 ` Johannes Weiner
2016-11-14 19:40 ` Kirill A. Shutemov
2016-11-15 14:00 ` Johannes Weiner
2016-11-07 19:07 ` [PATCH 2/6] mm: workingset: turn shadow node shrinker bugs into warnings Johannes Weiner
2016-11-08 9:57 ` Jan Kara
2016-11-07 19:07 ` [PATCH 3/6] lib: radix-tree: native accounting of exceptional entries Johannes Weiner
2016-11-08 10:08 ` Jan Kara
2016-11-07 19:07 ` [PATCH 4/6] lib: radix-tree: check accounting of existing slot replacement users Johannes Weiner
2016-11-08 10:12 ` Jan Kara
2016-11-07 19:07 ` [PATCH 5/6] mm: workingset: switch shadow entry tracking to radix tree exceptional counting Johannes Weiner
2016-11-08 10:27 ` Jan Kara
2016-11-08 19:30 ` Johannes Weiner [this message]
2016-11-07 19:07 ` [PATCH 6/6] mm: workingset: restore refault tracking for single-page files Johannes Weiner
2016-11-08 10:31 ` Jan Kara
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=20161108193011.GA15802@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=kernel-team@fb.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=torvalds@linux-foundation.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).