From: Andrew Morton <akpm@linux-foundation.org>
To: mateusznosek0@gmail.com
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] mm/page_alloc.c: Micro-optimisation Remove unnecessary branch
Date: Sat, 7 Mar 2020 15:15:42 -0800 [thread overview]
Message-ID: <20200307151542.b14131037dc44a8edcb22cad@linux-foundation.org> (raw)
In-Reply-To: <20200307225335.31300-1-mateusznosek0@gmail.com>
On Sat, 7 Mar 2020 23:53:35 +0100 mateusznosek0@gmail.com wrote:
> From: Mateusz Nosek <mateusznosek0@gmail.com>
>
> Previously if branch condition was false, the assignment was not executed.
> The assignment can be safely executed even when the condition is false and
> it is not incorrect as it assigns the value of 'nodemask' to 'ac.nodemask'
> which already has the same value.
>
> So as the assignment can be executed unconditionally, the branch can be
> removed.
>
> ...
>
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4819,8 +4819,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, int preferred_nid,
> * Restore the original nodemask if it was potentially replaced with
> * &cpuset_current_mems_allowed to optimize the fast-path attempt.
> */
> - if (unlikely(ac.nodemask != nodemask))
> - ac.nodemask = nodemask;
> + ac.nodemask = nodemask;
>
This will now unconditionally dirty the ac.nodemask cacheline, which
means that cacheline will need to be written back. If it is truly
unlikely that the write was needed then the thinking goes that the
test-and-branch is worthwhile, by saving on memory traffic.
At least, I assume that's why the code is the way it is.
I don't know whether this optimisation is valid on a majority of modern
platforms. But that's the thinking!
next prev parent reply other threads:[~2020-03-07 23:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-07 22:53 [RFC PATCH] mm/page_alloc.c: Micro-optimisation Remove unnecessary branch mateusznosek0
2020-03-07 23:15 ` Andrew Morton [this message]
2020-03-08 11:50 ` Matthew Wilcox
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=20200307151542.b14131037dc44a8edcb22cad@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mateusznosek0@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).