From: Hugh Dickins <hughd@google.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hugh Dickins <hughd@google.com>,
Petr Holasek <pholasek@redhat.com>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 3/6] ksm: don't fail stable tree lookups if walking over stale stable_nodes
Date: Sun, 25 Oct 2015 16:34:27 -0700 (PDT) [thread overview]
Message-ID: <alpine.LSU.2.11.1510251622340.1923@eggly.anvils> (raw)
In-Reply-To: <1444925065-4841-4-git-send-email-aarcange@redhat.com>
On Thu, 15 Oct 2015, Andrea Arcangeli wrote:
> The stable_nodes can become stale at any time if the underlying pages
> gets freed. The stable_node gets collected and removed from the stable
> rbtree if that is detected during the rbtree tree lookups.
>
> Don't fail the lookup if running into stale stable_nodes, just restart
> the lookup after collecting the stale entries. Otherwise the CPU spent
> in the preparation stage is wasted and the lookup must be repeated at
> the next loop potentially failing a second time in a second stale
> entry.
>
> This also will contribute to pruning the stable tree and releasing the
> stable_node memory more efficiently.
>
> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
I'll say
Acked-by: Hugh Dickins <hughd@google.com>
as a gesture of goodwill, but in honesty I'm sitting on the fence,
and couldn't decide. I think I've gone back and forth on this in
my own mind in the past, worried that we might get stuck a long
time going back round to "again". In the past I've felt that to
give up with NULL is consistent with KSM's willingness to give way
to any obstruction; but if you're finding "goto again" a better
strategy, sure, go ahead. And at least there's a cond_resched()
just above the diff context shown.
A dittoed nit below...
> ---
> mm/ksm.c | 30 +++++++++++++++++++++++++++---
> 1 file changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/mm/ksm.c b/mm/ksm.c
> index 39ef485..929b5c2 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -1225,7 +1225,18 @@ again:
> stable_node = rb_entry(*new, struct stable_node, node);
> tree_page = get_ksm_page(stable_node, false);
> if (!tree_page)
> - return NULL;
> + /*
> + * If we walked over a stale stable_node,
> + * get_ksm_page() will call rb_erase() and it
> + * may rebalance the tree from under us. So
> + * restart the search from scratch. Returning
> + * NULL would be safe too, but we'd generate
> + * false negative insertions just because some
> + * stable_node was stale which would waste CPU
> + * by doing the preparation work twice at the
> + * next KSM pass.
> + */
> + goto again;
When a comment gets that long, in fact even if it were only one line,
I'd much prefer that block inside braces. I think I noticed Linus
feeling the same way a few days ago, when he fixed up someone's patch.
>
> ret = memcmp_pages(page, tree_page);
> put_page(tree_page);
> @@ -1301,12 +1312,14 @@ static struct stable_node *stable_tree_insert(struct page *kpage)
> unsigned long kpfn;
> struct rb_root *root;
> struct rb_node **new;
> - struct rb_node *parent = NULL;
> + struct rb_node *parent;
> struct stable_node *stable_node;
>
> kpfn = page_to_pfn(kpage);
> nid = get_kpfn_nid(kpfn);
> root = root_stable_tree + nid;
> +again:
> + parent = NULL;
> new = &root->rb_node;
>
> while (*new) {
> @@ -1317,7 +1330,18 @@ static struct stable_node *stable_tree_insert(struct page *kpage)
> stable_node = rb_entry(*new, struct stable_node, node);
> tree_page = get_ksm_page(stable_node, false);
> if (!tree_page)
> - return NULL;
> + /*
> + * If we walked over a stale stable_node,
> + * get_ksm_page() will call rb_erase() and it
> + * may rebalance the tree from under us. So
> + * restart the search from scratch. Returning
> + * NULL would be safe too, but we'd generate
> + * false negative insertions just because some
> + * stable_node was stale which would waste CPU
> + * by doing the preparation work twice at the
> + * next KSM pass.
> + */
> + goto again;
Ditto.
>
> ret = memcmp_pages(kpage, tree_page);
> put_page(tree_page);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-10-25 23:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-15 16:04 [PATCH 0/6] KSM fixes Andrea Arcangeli
2015-10-15 16:04 ` [PATCH 1/6] ksm: fix rmap_item->anon_vma memory corruption and vma user after free Andrea Arcangeli
2015-10-26 0:12 ` Hugh Dickins
2015-10-30 18:55 ` Andrea Arcangeli
2015-10-15 16:04 ` [PATCH 2/6] ksm: add cond_resched() to the rmap_walks Andrea Arcangeli
2015-10-25 23:41 ` Hugh Dickins
2015-10-27 0:32 ` Davidlohr Bueso
2015-11-01 22:19 ` Andrea Arcangeli
2015-10-15 16:04 ` [PATCH 3/6] ksm: don't fail stable tree lookups if walking over stale stable_nodes Andrea Arcangeli
2015-10-25 23:34 ` Hugh Dickins [this message]
2015-11-01 23:03 ` Andrea Arcangeli
2015-10-15 16:04 ` [PATCH 4/6] ksm: use the helper method to do the hlist_empty check Andrea Arcangeli
2015-10-25 23:22 ` Hugh Dickins
2015-10-15 16:04 ` [PATCH 5/6] ksm: use find_mergeable_vma in try_to_merge_with_ksm_page Andrea Arcangeli
2015-10-25 23:21 ` Hugh Dickins
2015-10-15 16:04 ` [PATCH 6/6] ksm: unstable_tree_search_insert error checking cleanup Andrea Arcangeli
2015-10-25 23:18 ` Hugh Dickins
2015-11-01 23:45 ` Andrea Arcangeli
2015-11-02 0:23 ` Hugh Dickins
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=alpine.LSU.2.11.1510251622340.1923@eggly.anvils \
--to=hughd@google.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=pholasek@redhat.com \
/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