From: Matthew Wilcox <willy@infradead.org>
To: gaoxu <gaoxu2@honor.com>
Cc: Barry Song <21cnbao@gmail.com>, Mike Rapoport <rppt@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"surenb@google.com" <surenb@google.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
yipengxiang <yipengxiang@honor.com>
Subject: Re: [PATCH] mm: simplify zone_idx()
Date: Tue, 15 Apr 2025 15:49:00 +0100 [thread overview]
Message-ID: <Z_5x3AwzTWeBXoZB@casper.infradead.org> (raw)
In-Reply-To: <b2bde1ca046949599d74cb9e88c21ba3@honor.com>
On Tue, Apr 15, 2025 at 12:34:27PM +0000, gaoxu wrote:
> > Growing it doesn't feel like a big deal. Although "saves two assembly
> > instructions" is also not exactly a big win. If it saved a cacheline reference,
> > that might be more interesting, but it seems like it's more likely to introduce a
> > cacheline reference than save one. Maybe just not worth doing?
>
> Zone, zone_pgdat, and node_zones are all considered hot data; most of the time,
> they reside in the cache. In contrast, zone_idx in the patch is not hot data,
> and executing ((zone)->zone_idx) will add a new cache line.
> Am I understanding this correctly?
CPUs are not limited in the number of instructions they can execute today.
For example the ARM X4 can execute 8 instructions per clock. Most of
the time most of the CPU is idle, waiting on cache misses. A cache
miss (all the way to memory) is about 100ns, so if said CPU is clocked
at 3.4GHz, that's 2700 instructions that could be executed instead of
waiting for that cacheline. Other top-end CPUs have similar numbers;
you can find weak CPUs out there which have smaller ratios, but we don't
tend to optimise for low-end CPUs.
Therefore it is more important to avoid cacheline misses than it is to
reduce the number of instructions executed. You haven't measured any
improvement from your patch, so I think we should defaut to not
changing anything.
prev parent reply other threads:[~2025-04-15 14:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-10 12:03 gaoxu
2025-04-10 14:41 ` Mike Rapoport
2025-04-10 21:59 ` Barry Song
2025-04-12 8:34 ` 回复: " gaoxu
2025-04-12 9:15 ` Barry Song
2025-04-12 10:06 ` 回复: " gaoxu
2025-04-13 21:57 ` Barry Song
2025-04-13 23:20 ` Matthew Wilcox
2025-04-15 12:34 ` gaoxu
2025-04-15 14:49 ` Matthew Wilcox [this message]
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=Z_5x3AwzTWeBXoZB@casper.infradead.org \
--to=willy@infradead.org \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=gaoxu2@honor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=yipengxiang@honor.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