From: Paul Mackerras <paulus@samba.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Christoph Lameter <clameter@sgi.com>,
linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
benh@kernel.crashing.org, anton@samba.org
Subject: Re: Page fault scalability patch V18: Drop first acquisition of ptl
Date: Thu, 03 Mar 2005 05:00:10 +0000 [thread overview]
Message-ID: <16934.39386.686708.768378@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <20050302201425.2b994195.akpm@osdl.org>
Andrew Morton writes:
> But if the approach which these patches take is not suitable for these
> architectures then they have no solution to the scalability problem. The
> machines will perform suboptimally and more (perhaps conflicting)
> development will be needed.
We can do a pte_cmpxchg on ppc64. We already have a busy bit in the
PTE and do most operations atomically, in order to ensure that we
don't get races or inconsistencies due to accesses to the PTE by the
low-level hash_page() routine (which instantiates a hardware PTE in
the hardware hash table based on a Linux PTE), because it already
accesses the linux page tables without taking the mm->page_table_lock.
However, there are other developments we are considering in this area:
notably Ben wants to change things so that when we invalidate a Linux
PTE we leave it busy until we actually remove the hardware PTE from
the hash table. Also we are looking forward to DaveM's patch which
will change the generic MM code to give us the mm and address on all
PTE operations, which will simplify some things for us. I don't
really want to have to think about pte_cmpxchg until those other
things are sorted out.
More generally, I would be interested to know what sorts of
applications or benchmarks show scalability problems on large machines
due to contention on mm->page_table_lock.
Paul.
next prev parent reply other threads:[~2005-03-03 5:00 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-02 3:49 Page fault scalability patch V18: Overview Christoph Lameter
2005-03-02 3:50 ` Page fault scalability patch V18: atomic pte ops, pte_cmpxchg Christoph Lameter
2005-03-02 3:51 ` Page fault scalability patch V18: abstract rss counter ops Christoph Lameter
2005-03-02 3:51 ` Page fault scalability patch V18: Drop first acquisition of ptl Christoph Lameter
2005-03-03 1:45 ` Andrew Morton
2005-03-03 2:13 ` Christoph Lameter
2005-03-03 2:55 ` Andrew Morton
2005-03-03 3:17 ` Christoph Lameter
2005-03-03 4:14 ` Andrew Morton
2005-03-03 4:27 ` Christoph Lameter
2005-03-03 4:56 ` Andrew Morton
2005-03-03 5:17 ` Christoph Lameter
2005-03-03 5:37 ` Andrew Morton
2005-03-03 5:48 ` Christoph Lameter
2005-03-03 6:13 ` Christoph Lameter
2005-03-03 6:20 ` Andrew Morton
2005-03-03 16:54 ` Christoph Lameter
2005-03-03 21:20 ` Andrew Morton
2005-03-03 22:14 ` Christoph Lameter
2005-03-04 16:44 ` Christoph Lameter
2005-03-04 17:09 ` Hugh Dickins
2005-03-04 18:29 ` Christoph Lameter
2005-03-04 19:08 ` Hugh Dickins
2005-03-31 6:55 ` Avoid spurious page faults by avoiding pte_clear -> set pte Christoph Lameter
2005-03-04 16:46 ` Page fault scalability patch V18: Drop first acquisition of ptl Christoph Lameter
2005-03-03 5:00 ` Paul Mackerras [this message]
2005-03-03 5:19 ` Christoph Lameter
2005-03-03 5:38 ` David S. Miller
2005-03-03 5:51 ` Christoph Lameter
2005-03-03 6:11 ` Benjamin Herrenschmidt
2005-03-03 16:52 ` Christoph Lameter
2005-03-03 5:54 ` Benjamin Herrenschmidt
2005-03-03 6:37 ` Nick Piggin
2005-03-03 6:30 ` Benjamin Herrenschmidt
2005-03-03 7:44 ` Nick Piggin
2005-03-03 17:43 ` David S. Miller
2005-03-03 5:24 ` Nick Piggin
2005-03-02 3:52 ` Page fault scalability patch V18: No page table lock in do_anonymous_page Christoph Lameter
2005-03-04 2:18 ` Page fault scalability patch V18: Overview Darren Williams
2005-03-04 2:47 ` Darren Williams
2005-03-04 16:15 ` Christoph Lameter
2005-03-06 21:49 ` Darren Williams
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=16934.39386.686708.768378@cargo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=akpm@osdl.org \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=clameter@sgi.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.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