From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: "Benjamin C.R. LaHaise" <blah@kvack.org>,
"Theodore Y. Ts'o" <tytso@mit.edu>,
linux-kernel@vger.kernel.org,
MM mailing list <linux-mm@kvack.org>
Subject: Re: [RFC] atomic pte updates for x86 smp
Date: Thu, 12 Oct 2000 10:13:48 +0200 (CEST) [thread overview]
Message-ID: <Pine.LNX.4.21.0010120921510.1191-100000@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.10.10010112318110.2852-100000@penguin.transmeta.com>
On Wed, 11 Oct 2000, Linus Torvalds wrote:
> (Instead of doing an atomic 64-bit memory write, we would be doing the
> atomic "pte_xchg_clear()" followed by two _non_atomic 32-bit writes where
> the second write would set the present bit. Although maybe the erratum
> about the PAE pgd entry not honoring the P bit correctly makes this be
> unworkable).
>
> Ingo? I'd really like you to take a long look at this patch for sanity,
> especially wrt PAE.
the PAE pgd 'anomaly' should not affect this case, because we never clear
neither user-space pgds, nor user-space pmds in PAE mode. Unless we start
swapping pagetables i dont think this will ever happen in the future. The
PAE anomaly only affects the four top-level pgds, so even if we started
swapping pagetables, we'll never have to swap the pgds themselves.
i completely agree with the need to clean the pte-setting atomicity
interface up. And getting rid of cmpxch8b will be a definite performance
(and GCC-optimization) improvement.
> After this patch, are there any cases where we do a "set_pte()" where
> the PTE wasn't clear before? That might be a good sanity-test to add,
> just to make sure. And I'd really like to speed up the PAE set_pte() -
> as far as I can tell both set_pte and set_pmd really should be safe
> without the atomic 64-bit crap with your changes.
yep, the two 32-bit writes idea is very nice - this should be safe - and
there isnt even any need for any barriers (except optimization barrier),
given that writes are strongly ordered on x86.
my gut feeling is that all these things will only benefit PAE support, and
the risk of those changes is low, none of those should bite us in the
future, design-wise. And it's also a nice speedup. And after this we could
finally get rid of the 'unsigned long long' as well and just define two
32-bit fields in pte.
Ingo
--
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.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-10-12 8:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200010090419.e994JQT09775@trampoline.thunk.org>
2000-10-10 20:53 ` Updated 2.4 TODO List Rik van Riel
2000-10-11 0:06 ` 2.4.0test9 vm: disappointing streaming i/o under load Chris Evans
2000-10-11 11:38 ` Eric Lowe
2000-10-11 20:59 ` Chris Evans
2000-10-11 22:10 ` Roger Larsson
2000-10-11 22:46 ` Chris Evans
2000-10-13 16:57 ` Rik van Riel
2000-10-11 18:38 ` Updated 2.4 TODO List tytso
2000-10-11 23:52 ` [RFC] atomic pte updates for x86 smp Ben LaHaise
2000-10-12 0:09 ` Linus Torvalds
2000-10-12 4:03 ` Benjamin C.R. LaHaise
2000-10-12 4:06 ` David S. Miller
2000-10-12 4:31 ` Cort Dougan
2000-10-12 4:37 ` Benjamin C.R. LaHaise
2000-10-12 6:42 ` Linus Torvalds
2000-10-12 8:13 ` Ingo Molnar [this message]
2000-10-12 8:56 ` David S. Miller
2000-10-12 10:05 ` Ingo Molnar
2000-10-12 11:10 ` Ingo Molnar
2000-10-12 15:10 ` Benjamin C.R. LaHaise
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=Pine.LNX.4.21.0010120921510.1191-100000@elte.hu \
--to=mingo@elte.hu \
--cc=blah@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=torvalds@transmeta.com \
--cc=tytso@mit.edu \
/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