From: Minchan Kim <minchan@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Dave Chinner <david@fromorbit.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock
Date: Thu, 30 Nov 2017 09:53:01 +0900 [thread overview]
Message-ID: <20171130005301.GA2679@bbox> (raw)
In-Reply-To: <1511965054-6328-1-git-send-email-longman@redhat.com>
Hello,
On Wed, Nov 29, 2017 at 09:17:34AM -0500, Waiman Long wrote:
> The list_lru_del() function removes the given item from the LRU list.
> The operation looks simple, but it involves writing into the cachelines
> of the two neighboring list entries in order to get the deletion done.
> That can take a while if the cachelines aren't there yet, thus
> prolonging the lock hold time.
>
> To reduce the lock hold time, the cachelines of the two neighboring
> list entries are now prefetched before acquiring the list_lru_node's
> lock.
>
> Using a multi-threaded test program that created a large number
> of dentries and then killed them, the execution time was reduced
> from 38.5s to 36.6s after applying the patch on a 2-socket 36-core
> 72-thread x86-64 system.
>
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> mm/list_lru.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/mm/list_lru.c b/mm/list_lru.c
> index f141f0c..65aae44 100644
> --- a/mm/list_lru.c
> +++ b/mm/list_lru.c
> @@ -132,8 +132,16 @@ bool list_lru_del(struct list_lru *lru, struct list_head *item)
> struct list_lru_node *nlru = &lru->node[nid];
> struct list_lru_one *l;
>
> + /*
> + * Prefetch the neighboring list entries to reduce lock hold time.
> + */
> + if (unlikely(list_empty(item)))
> + return false;
> + prefetchw(item->prev);
> + prefetchw(item->next);
> +
A question:
A few month ago, I had a chance to measure prefetch effect with my testing
workload. For the clarification, it's not list_lru_del but list traverse
stuff so it might be similar.
With my experiment at that time, it was really hard to find best place to
add prefetchw. Sometimes, it was too eariler or late so the effect was
not good, even worse on some cases.
Also, the performance was different with each machine although my testing
machines was just two. ;-)
So my question is what's a rule of thumb to add prefetch command?
Like your code, putting prefetch right before touching?
I'm really wonder what's the rule to make every arch/machines happy
with prefetch.
> spin_lock(&nlru->lock);
> - if (!list_empty(item)) {
> + if (likely(!list_empty(item))) {
> l = list_lru_from_kmem(nlru, item);
> list_del_init(item);
> l->nr_items--;
> --
> 1.8.3.1
>
> --
> 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>
--
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:[~2017-11-30 0:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-29 14:17 [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock Waiman Long
2017-11-29 21:53 ` Andrew Morton
2017-11-30 0:42 ` Dave Chinner
2017-11-30 13:54 ` Waiman Long
2017-11-30 20:38 ` Dave Chinner
2017-11-30 20:55 ` Waiman Long
2017-11-30 20:47 ` Andrew Morton
2017-11-30 20:49 ` Waiman Long
2017-12-01 0:09 ` Minchan Kim
2017-12-01 14:14 ` Waiman Long
2017-12-01 22:02 ` Dave Chinner
2017-11-30 0:53 ` Minchan Kim [this message]
2017-11-30 13:43 ` Waiman Long
2017-11-30 23:53 ` Minchan Kim
2017-11-30 14:34 ` Matthew Wilcox
2017-12-05 14:49 ` Michal Hocko
2017-12-05 23:56 ` Andrew Morton
2017-12-06 8:07 ` Michal Hocko
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=20171130005301.GA2679@bbox \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=vdavydov.dev@gmail.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;
as well as URLs for NNTP newsgroup(s).