From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: Nicholas Piggin <npiggin@gmail.com>,
Anton Blanchard <anton@ozlabs.org>, Arnd Bergmann <arnd@arndb.de>,
linux-arch <linux-arch@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
X86 ML <x86@kernel.org>, Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Rik van Riel <riel@surriel.com>,
Dave Hansen <dave.hansen@intel.com>
Subject: Re: [MOCKUP] x86/mm: Lightweight lazy mm refcounting
Date: Thu, 3 Dec 2020 09:44:48 +0100 [thread overview]
Message-ID: <20201203084448.GF2414@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <7c4bcc0a464ca60be1e0aeba805a192be0ee81e5.1606972194.git.luto@kernel.org>
On Wed, Dec 02, 2020 at 09:25:51PM -0800, Andy Lutomirski wrote:
> power: same as ARM, except that the loop may be rather larger since
> the systems are bigger. But I imagine it's still faster than Nick's
> approach -- a cmpxchg to a remote cacheline should still be faster than
> an IPI shootdown.
While a single atomic might be cheaper than an IPI, the comparison
doesn't work out nicely. You do the xchg() on every unlazy, while the
IPI would be once per process exit.
So over the life of the process, it might do very many unlazies, adding
up to a total cost far in excess of what the single IPI would've been.
And while I appreciate all the work to get rid of the active_mm
accounting; the worry I have with pushing this all into arch code is
that it will be so very easy to get this subtly wrong.
next prev parent reply other threads:[~2020-12-03 8:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 5:25 Andy Lutomirski
2020-12-03 7:11 ` kernel test robot
2020-12-03 8:44 ` Peter Zijlstra [this message]
2020-12-03 22:13 ` Nicholas Piggin
2020-12-04 2:17 ` Andy Lutomirski
2020-12-03 12:31 ` Matthew Wilcox
2020-12-03 14:26 ` Rik van Riel
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=20201203084448.GF2414@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=anton@ozlabs.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=npiggin@gmail.com \
--cc=riel@surriel.com \
--cc=will@kernel.org \
--cc=x86@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