From: Linus Torvalds <torvalds@linux-foundation.org>
To: Nicholas Piggin <npiggin@gmail.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-arch <linux-arch@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v6 4/5] powerpc/64s: enable MMU_LAZY_TLB_SHOOTDOWN
Date: Wed, 18 Jan 2023 09:30:22 -0800 [thread overview]
Message-ID: <CAHk-=wiLaY7K6N4VF=wgS+AVsFi298fMA3Tx6rzbbP7xT+1Dqg@mail.gmail.com> (raw)
In-Reply-To: <20230118080011.2258375-5-npiggin@gmail.com>
[ Adding a few more x86 and arm64 maintainers - while linux-arch is
the right mailing list, I'm not convinced people actually follow it
all that closely ]
On Wed, Jan 18, 2023 at 12:00 AM Nicholas Piggin <npiggin@gmail.com> wrote:
>
> On a 16-socket 192-core POWER8 system, a context switching benchmark
> with as many software threads as CPUs (so each switch will go in and
> out of idle), upstream can achieve a rate of about 1 million context
> switches per second, due to contention on the mm refcount.
>
> 64s meets the prerequisites for CONFIG_MMU_LAZY_TLB_SHOOTDOWN, so enable
> the option. This increases the above benchmark to 118 million context
> switches per second.
Well, the 1M -> 118M change does seem like a good reason for this series.
The patches certainly don't look offensive to me, so Ack as far as I'm
concerned, but honestly, it's been some time since I've personally
been active on the idle and lazy TLB code, so that ack is probably
largely worthless.
If anything, my main reaction to this all is to wonder whether the
config option is a good idea - maybe we could do this unconditionally,
and make the source code (and logic) simpler to follow when you don't
have to worry about the CONFIG_MMU_LAZY_TLB_REFCOUNT option.
I wouldn't be surprised to hear that x86 can have the same issue where
the mm_struct refcount is a bigger issue than the possibility of an
extra TLB shootdown at the final exit time.
But having the config options as a way to switch people over gradually
(and perhaps then removing it later) doesn't sound wrong to me either.
And I personally find the argument in patch 3/5 fairly convincing:
Shootdown IPIs cost could be an issue, but they have not been observed
to be a serious problem with this scheme, because short-lived processes
tend not to migrate CPUs much, therefore they don't get much chance to
leave lazy tlb mm references on remote CPUs.
Andy? PeterZ? Catalin?
Nick - it might be good to link to the actual benchmark, and let
people who have access to big machines perhaps just try it out on
non-powerpc platforms...
Linus
next prev parent reply other threads:[~2023-01-18 17:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-18 8:00 [PATCH v6 0/5] shoot lazy tlbs Nicholas Piggin
2023-01-18 8:00 ` [PATCH v6 1/5] lazy tlb: introduce lazy tlb mm refcount helper functions Nicholas Piggin
2023-01-18 8:00 ` [PATCH v6 2/5] lazy tlb: allow lazy tlb mm refcounting to be configurable Nicholas Piggin
2023-01-23 7:35 ` Nadav Amit
2023-01-23 8:02 ` Nadav Amit
2023-01-24 2:29 ` Nicholas Piggin
2023-01-18 8:00 ` [PATCH v6 3/5] lazy tlb: shoot lazies, non-refcounting lazy tlb mm reference handling scheme Nicholas Piggin
2023-01-18 22:22 ` Nadav Amit
2023-01-19 0:53 ` Nicholas Piggin
2023-01-19 4:22 ` Nicholas Piggin
2023-01-23 8:16 ` Nadav Amit
2023-01-24 3:16 ` Nicholas Piggin
2023-01-18 8:00 ` [PATCH v6 4/5] powerpc/64s: enable MMU_LAZY_TLB_SHOOTDOWN Nicholas Piggin
2023-01-18 17:30 ` Linus Torvalds [this message]
2023-01-19 3:04 ` Nicholas Piggin
2023-01-18 8:00 ` [PATCH v6 5/5] powerpc/64s/radix: combine final TLB flush and lazy tlb mm shootdown IPIs Nicholas Piggin
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='CAHk-=wiLaY7K6N4VF=wgS+AVsFi298fMA3Tx6rzbbP7xT+1Dqg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/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