linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hugh@veritas.com>
To: Daniel Phillips <phillips@bonn-fries.net>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	dmccr@us.ibm.com,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, Robert Love <rml@tech9.net>,
	Rik van Riel <riel@conectiva.com.br>,
	mingo@redhat.co, Andrew Morton <akpm@zip.com.au>,
	manfred@colorfullife.com, wli@holomorphy.com
Subject: Re: [RFC] Page table sharing
Date: Mon, 18 Feb 2002 19:04:43 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.21.0202181759100.1248-100000@localhost.localdomain> (raw)
In-Reply-To: <E16ckIC-0000KV-00@starship.berlin>

On Mon, 18 Feb 2002, Daniel Phillips wrote:
> On February 18, 2002 09:09 am, Hugh Dickins wrote:
> 
> > So how is the page_table_lock taken by swap_out effective when it's
> > dealing with a page table shared by another mm than the one it is
> > locking?  And when handling a read-fault, again no such code (but
> > when handling a write-fault, __pte_alloc has unshared in advance).
> >
> > Since copy_page_range would not copy shared page tables, I'm wrong to
> > point there.  But __pte_alloc does copy shared page tables (to unshare
> > them), and needs them to be stable while it does so: so locking against
> > swap_out really is required.  It also needs locking against read faults,
> > and they against each other: but there I imagine it's just a matter of
> > dropping the write arg to __pte_alloc, going back to pte_alloc again.
> 
> You're right about the read faults, wrong about swap_out.  In general you've 
> been more right than wrong, so thanks.  I'll post a new patch pretty soon and 
> I'd appreciate your comments.

On the read faults: I see no change there in the patch you then posted,
handle_mm_fault still calls __pte_alloc with write_access argument, so
concurrent read faults on the same pte can still slot the page into the
shared page table at the same time, doubly counting it - no problem if
it's the Reserved empty_zero_page, and I think no problem at present
if it's a SwapCache page, since that is PageLocked in the current tree
(but not in -aa, and in due course we should go Andrea's way there);
but if it's a file page the double count will leave it unfreeable.

On swap_out versus __pte_alloc: I was misreading it and you're almost
right there: but you do need to change that "pte_t pte = *src_ptb;"
to something atomic - hmm, do we have any primitive for doing that?
neither set_pte nor ptep_get_and_clear is right.  Otherwise, on PAE
HIGHMEM64G systems the two halves of "pte" could be assigned before
and after try_to_swap_out's ptep_get_and_clear.  But once you've got
"pte", yes, you're basing all your decisions on your one local copy,
that gives all the stability you need.

Hugh

(By the way, the patch you appended to your next mail did not apply
- I think you'd hand-edited an incidental irrelevant cleanup out of
the patch to memory.c, without adjusting its line counts; and also
had to edit "public_html/" out of the URL you gave.)

--
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-mm.org/

  parent reply	other threads:[~2002-02-18 19:04 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.33.0202162219230.8326-100000@home.transmeta.com>
2002-02-17 19:39 ` Daniel Phillips
2002-02-17 20:16   ` Daniel Phillips
2002-02-17 22:16   ` Hugh Dickins
2002-02-18  1:35     ` Daniel Phillips
2002-02-18  8:09       ` Hugh Dickins
2002-02-18  9:41         ` Daniel Phillips
2002-02-18 11:32           ` Daniel Phillips
2002-02-18 19:04           ` Hugh Dickins [this message]
2002-02-18 23:37             ` Daniel Phillips
2002-02-19  0:56               ` Linus Torvalds
2002-02-19  1:22                 ` Rik van Riel
2002-02-19  1:29                   ` Daniel Phillips
2002-02-19  1:48                   ` Linus Torvalds
2002-02-19  1:53                     ` Rik van Riel
2002-02-19  2:05                       ` Linus Torvalds
2002-02-19  2:22                         ` Daniel Phillips
2002-02-19  2:35                           ` Linus Torvalds
2002-02-19  2:55                             ` Daniel Phillips
2002-02-19  3:11                             ` Daniel Phillips
2002-02-19  3:22                             ` Linus Torvalds
2002-02-19  3:45                               ` Daniel Phillips
2002-02-19 17:29                                 ` Linus Torvalds
2002-02-19 18:11                                   ` Hugh Dickins
2002-02-20 14:18                                     ` Daniel Phillips
2002-02-20 15:30                                       ` Hugh Dickins
2002-02-20 14:10                                   ` Daniel Phillips
2002-02-20 14:38                                     ` Hugh Dickins
2002-02-20 14:57                                       ` Daniel Phillips
2002-02-19 11:39                               ` Daniel Phillips
2002-02-19 12:22                                 ` Hugh Dickins
2002-02-19 12:43                                   ` Daniel Phillips
2002-02-19 10:02                             ` Roman Zippel
2002-02-22  5:29                         ` Daniel Phillips
2002-02-22  6:32                           ` Daniel Phillips
2002-02-22  9:21                             ` [RFC] Page table sharing, leak gone Daniel Phillips
2002-02-19  1:57                     ` [RFC] Page table sharing Daniel Phillips
2002-02-19  1:23                 ` Daniel Phillips
2002-02-19  1:50                 ` Daniel Phillips
2002-02-19  1:53                   ` Linus Torvalds
2002-02-19  2:12                     ` Daniel Phillips
2002-02-18 23:48             ` Daniel Phillips
2002-02-18 23:59             ` Daniel Phillips
2002-02-19  0:03               ` Hugh Dickins
2002-02-19  0:27                 ` Daniel Phillips
2002-02-19  4:27                   ` Eric W. Biederman
2002-02-19 17:30                     ` Linus Torvalds
2002-02-19 18:18 Qing Huang

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.0202181759100.1248-100000@localhost.localdomain \
    --to=hugh@veritas.com \
    --cc=akpm@zip.com.au \
    --cc=dmccr@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=manfred@colorfullife.com \
    --cc=mingo@redhat.co \
    --cc=phillips@bonn-fries.net \
    --cc=riel@conectiva.com.br \
    --cc=rml@tech9.net \
    --cc=torvalds@transmeta.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