public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Rajesh Venkatasubramanian <vrajesh@umich.edu>
To: Hugh Dickins <hugh@veritas.com>,
	William Lee Irwin III <wli@holomorphy.com>,
	"David S. Miller" <davem@redhat.com>,
	raybry@sgi.com, ak@muc.de, benh@kernel.crashing.org,
	manfred@colorfullife.com, linux-ia64@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: page fault fastpath patch v2: fix race conditions, stats for 8,32     and    512 cpu SMP
Date: Wed, 18 Aug 2004 23:50:21 +0000	[thread overview]
Message-ID: <pan.2004.08.18.23.50.13.562750@umich.edu> (raw)
In-Reply-To: 2uCTq-2wa-55@gated-at.bofh.it

William Lee Irwin III wrote:
> On Wed, Aug 18, 2004 at 06:55:07PM +0100, Hugh Dickins wrote:
>> That's interesting, and disappointing.
>> The main lesson I took from your patch (I think wli was hinting at
>> the same) is that we ought now to question page_table_lock usage,
>> should be possible to cut it a lot.
>> I recall from exchanges with Dave McCracken 18 months ago that the
>> page_table_lock is _almost_ unnecessary in rmap.c, should be possible
>> to get avoid it there and in some other places.
>> We take page_table_lock when making absent present and when making
>> present absent: I like your observation that those are exclusive cases.
>> But you've found that narrowing the width of the page_table_lock
>> in a particular path does not help.  You sound surprised, me too.
>> Did you find out why that was?
>
> It also protects against vma tree modifications in mainline, but rmap.c
> shouldn't need it for vmas anymore, as the vma is rooted to the spot by
> mapping->i_shared_lock for file pages and anon_vma->lock for anonymous.

If I am reading the code correctly, then without page_table_lock
in page_referenced_one(), we can race with exit_mmap() and page 
table pages can be freed under us.

William Lee Irwin III wrote:
> On Wed, Aug 18, 2004 at 06:55:07PM +0100, Hugh Dickins wrote:
>> I do think this will be a more fruitful direction than pte locking:
>> just looking through the arches for spare bits puts me off pte locking.
>
> Fortunately, spare bits aren't strictly necessary, and neither is
> cmpxchg. A single invalid value can serve in place of a bitflag. When
> using such an invalid value, just xchg()'ing it and looping when the
> invalid value is seen should suffice. This holds more generally for all
> radix trees, not just pagetables, and happily xchg() or emulation
> thereof is required by core code for all arches.

Good point. 

Another solution may be to use the unused bytes (->lru or
->private) in page table "struct page" as bit_spin_locks. We can 
use a single bit to protect a small set of ptes (8, 16, or 32).

Rajesh
  



       reply	other threads:[~2004-08-18 23:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2uexw-1Nn-1@gated-at.bofh.it>
     [not found] ` <2uCTq-2wa-55@gated-at.bofh.it>
2004-08-18 23:50   ` Rajesh Venkatasubramanian [this message]
2004-08-19  0:01     ` page fault fastpath patch v2: fix race conditions, stats for 8,32 and 512 cpu SMP William Lee Irwin III
2004-08-19  0:07       ` page fault fastpath patch v2: fix race conditions, stats for Rajesh Venkatasubramanian
2004-08-19  0:20         ` page fault fastpath patch v2: fix race conditions, stats for 8,32 and 512 cpu SMP William Lee Irwin III
2004-08-19  3:19           ` page fault fastpath patch v2: fix race conditions, stats for Rajesh Venkatasubramanian
2004-08-19  3:31             ` page fault fastpath patch v2: fix race conditions, stats for 8,32 and 512 cpu SMP William Lee Irwin III
2004-08-19  3:41               ` William Lee Irwin III
2004-08-23 22:00           ` page fault fastpath patch v2: fix race conditions, stats for Christoph Lameter
2004-08-23 23:25             ` Rajesh Venkatasubramanian
2004-08-23 23:35               ` Christoph Lameter
     [not found] <fa.ofiojek.hkeujs@ifi.uio.no>
     [not found] ` <fa.o1kt2ua.1bm6n0c@ifi.uio.no>
2004-08-18 20:13   ` Ray Bryant
2004-08-18 20:48     ` page fault fastpath patch v2: fix race conditions, stats for 8,32 and 512 cpu SMP William Lee Irwin III
2004-08-15 13:50 page fault fastpath: Increasing SMP scalability by introducing pte Christoph Lameter
2004-08-15 20:09 ` page fault fastpath: Increasing SMP scalability by introducing David S. Miller
2004-08-15 22:58   ` Christoph Lameter
2004-08-15 23:58     ` David S. Miller
2004-08-16  0:11       ` Christoph Lameter
2004-08-16  1:56         ` David S. Miller
2004-08-16  3:29           ` Christoph Lameter
2004-08-16 14:39             ` page fault fastpath: Increasing SMP scalability by introducing pte locks? William Lee Irwin III
2004-08-17 15:28               ` page fault fastpath patch v2: fix race conditions, stats for 8,32 Christoph Lameter
2004-08-17 15:37                 ` page fault fastpath patch v2: fix race conditions, stats for 8,32 and 512 cpu SMP Christoph Hellwig
2004-08-17 15:51                 ` William Lee Irwin III
2004-08-18 17:55                 ` page fault fastpath patch v2: fix race conditions, stats for 8,32 Hugh Dickins
2004-08-18 20:20                   ` page fault fastpath patch v2: fix race conditions, stats for 8,32 and 512 cpu SMP William Lee Irwin III

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=pan.2004.08.18.23.50.13.562750@umich.edu \
    --to=vrajesh@umich.edu \
    --cc=ak@muc.de \
    --cc=benh@kernel.crashing.org \
    --cc=davem@redhat.com \
    --cc=hugh@veritas.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=raybry@sgi.com \
    --cc=wli@holomorphy.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