From: Andrew Morton <akpm@linux-foundation.org>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Jesper Dangaard Brouer <brouer@redhat.com>,
rostedt@goodmis.org, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2 2/2] mm: don't use compound_head() in virt_to_head_page()
Date: Thu, 15 Jan 2015 17:16:46 -0800 [thread overview]
Message-ID: <20150115171646.8fec31e2.akpm@linux-foundation.org> (raw)
In-Reply-To: <1421307633-24045-2-git-send-email-iamjoonsoo.kim@lge.com>
On Thu, 15 Jan 2015 16:40:33 +0900 Joonsoo Kim <iamjoonsoo.kim@lge.com> wrote:
> compound_head() is implemented with assumption that there would be
> race condition when checking tail flag. This assumption is only true
> when we try to access arbitrary positioned struct page.
>
> The situation that virt_to_head_page() is called is different case.
> We call virt_to_head_page() only in the range of allocated pages,
> so there is no race condition on tail flag. In this case, we don't
> need to handle race condition and we can reduce overhead slightly.
> This patch implements compound_head_fast() which is similar with
> compound_head() except tail flag race handling. And then,
> virt_to_head_page() uses this optimized function to improve performance.
>
> I saw 1.8% win in a fast-path loop over kmem_cache_alloc/free,
> (14.063 ns -> 13.810 ns) if target object is on tail page.
>
> ...
>
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -453,6 +453,13 @@ static inline struct page *compound_head(struct page *page)
> return page;
> }
>
> +static inline struct page *compound_head_fast(struct page *page)
> +{
> + if (unlikely(PageTail(page)))
> + return page->first_page;
> + return page;
> +}
Can we please have some code comments which let people know when they
should and shouldn't use compound_head_fast()? I shouldn't have to say
this :(
> /*
> * The atomic page->_mapcount, starts from -1: so that transitions
> * both from it and to it can be tracked, using atomic_inc_and_test
> @@ -531,7 +538,8 @@ static inline void get_page(struct page *page)
> static inline struct page *virt_to_head_page(const void *x)
> {
> struct page *page = virt_to_page(x);
> - return compound_head(page);
> +
> + return compound_head_fast(page);
And perhaps some explanation here as to why virt_to_head_page() can
safely use compound_head_fast(). There's an assumption here that
nobody will be dismantling the compound page while virt_to_head_page()
is in progress, yes? And this assumption also holds for the calling
code, because otherwise the virt_to_head_page() return value is kinda
meaningless.
This is tricky stuff - let's spell it out carefully.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Jesper Dangaard Brouer <brouer@redhat.com>,
rostedt@goodmis.org, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2 2/2] mm: don't use compound_head() in virt_to_head_page()
Date: Thu, 15 Jan 2015 17:16:46 -0800 [thread overview]
Message-ID: <20150115171646.8fec31e2.akpm@linux-foundation.org> (raw)
In-Reply-To: <1421307633-24045-2-git-send-email-iamjoonsoo.kim@lge.com>
On Thu, 15 Jan 2015 16:40:33 +0900 Joonsoo Kim <iamjoonsoo.kim@lge.com> wrote:
> compound_head() is implemented with assumption that there would be
> race condition when checking tail flag. This assumption is only true
> when we try to access arbitrary positioned struct page.
>
> The situation that virt_to_head_page() is called is different case.
> We call virt_to_head_page() only in the range of allocated pages,
> so there is no race condition on tail flag. In this case, we don't
> need to handle race condition and we can reduce overhead slightly.
> This patch implements compound_head_fast() which is similar with
> compound_head() except tail flag race handling. And then,
> virt_to_head_page() uses this optimized function to improve performance.
>
> I saw 1.8% win in a fast-path loop over kmem_cache_alloc/free,
> (14.063 ns -> 13.810 ns) if target object is on tail page.
>
> ...
>
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -453,6 +453,13 @@ static inline struct page *compound_head(struct page *page)
> return page;
> }
>
> +static inline struct page *compound_head_fast(struct page *page)
> +{
> + if (unlikely(PageTail(page)))
> + return page->first_page;
> + return page;
> +}
Can we please have some code comments which let people know when they
should and shouldn't use compound_head_fast()? I shouldn't have to say
this :(
> /*
> * The atomic page->_mapcount, starts from -1: so that transitions
> * both from it and to it can be tracked, using atomic_inc_and_test
> @@ -531,7 +538,8 @@ static inline void get_page(struct page *page)
> static inline struct page *virt_to_head_page(const void *x)
> {
> struct page *page = virt_to_page(x);
> - return compound_head(page);
> +
> + return compound_head_fast(page);
And perhaps some explanation here as to why virt_to_head_page() can
safely use compound_head_fast(). There's an assumption here that
nobody will be dismantling the compound page while virt_to_head_page()
is in progress, yes? And this assumption also holds for the calling
code, because otherwise the virt_to_head_page() return value is kinda
meaningless.
This is tricky stuff - let's spell it out carefully.
next prev parent reply other threads:[~2015-01-16 1:17 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-15 7:40 [PATCH v2 1/2] mm/slub: optimize alloc/free fastpath by removing preemption on/off Joonsoo Kim
2015-01-15 7:40 ` Joonsoo Kim
2015-01-15 7:40 ` [PATCH v2 2/2] mm: don't use compound_head() in virt_to_head_page() Joonsoo Kim
2015-01-15 7:40 ` Joonsoo Kim
2015-01-16 1:16 ` Andrew Morton [this message]
2015-01-16 1:16 ` Andrew Morton
2015-01-16 3:30 ` Christoph Lameter
2015-01-16 3:30 ` Christoph Lameter
2015-01-19 4:20 ` 答复: " Zhang, Yanfei
2015-01-19 6:16 ` Joonsoo Kim
2015-01-19 6:16 ` Joonsoo Kim
2015-01-15 8:10 ` [PATCH v2 1/2] mm/slub: optimize alloc/free fastpath by removing preemption on/off Jesper Dangaard Brouer
2015-01-15 8:10 ` Jesper Dangaard Brouer
2015-01-16 1:16 ` Andrew Morton
2015-01-16 1:16 ` Andrew Morton
2015-01-16 1:30 ` Steven Rostedt
2015-01-16 1:30 ` Steven Rostedt
2015-01-16 3:27 ` Christoph Lameter
2015-01-16 3:27 ` Christoph Lameter
2015-01-16 3:51 ` Steven Rostedt
2015-01-16 3:51 ` Steven Rostedt
2015-01-16 3:57 ` Christoph Lameter
2015-01-16 3:57 ` Christoph Lameter
2015-01-16 4:07 ` Steven Rostedt
2015-01-16 4:07 ` Steven Rostedt
2015-01-16 13:40 ` Eric Dumazet
2015-01-16 13:40 ` Eric Dumazet
2015-01-16 16:37 ` Steven Rostedt
2015-01-16 16:37 ` Steven Rostedt
2015-01-16 4:04 ` Steven Rostedt
2015-01-16 4:04 ` Steven Rostedt
2015-01-16 3:28 ` Christoph Lameter
2015-01-16 3:28 ` Christoph Lameter
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=20150115171646.8fec31e2.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=brouer@redhat.com \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.