From: Daniel Phillips <phillips@bonn-fries.net>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Hugh Dickins <hugh@veritas.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: Tue, 19 Feb 2002 02:23:35 +0100 [thread overview]
Message-ID: <E16cz0J-0000yQ-00@starship.berlin> (raw)
In-Reply-To: <Pine.LNX.4.33.0202181631120.24405-100000@home.transmeta.com>
On February 19, 2002 01:56 am, Linus Torvalds wrote:
> On Tue, 19 Feb 2002, Daniel Phillips wrote:
> >
> > Thanks, here it is again. This time I left the gratuitous whitespace
> > cleanup in as the route of least resistance ;-)
>
> Daniel, there's something wrong in the locking.
>
> I can see _no_ reason to have "page_table_share_lock". What is the point
> of that one?
Before I put it in I was getting a weird error trying to run UML on a
native kernel with page table sharing. After it was solid. That's emprical,
but...
> Whenever we end up touching the pmd counts, we already hold the local
> mm->page_table_lock. That means that we are always guaranteed to have a
> count of at least one when we start out on it.
Yes, good observation, I was looking at it inversely: when we have a
count of one then we must have exclusion from the mm->page_table_lock.
> [...]
>
> In short, I do not believe that that lock is needed. And if it isn't
> needed, it is _incorrect_. Locking that doesn't buy you anything is not
> just a performance overhead, it's bad thinking.
It would be very nice if the lock isn't needed. OK, it's going to take some
time to ponder over your post properly. In the mean time, there is exclusion
that's clearly missing elsewhere and needs to go it, i.e., in the read fault
path.
--
Daniel
--
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/
next prev parent reply other threads:[~2002-02-19 1:23 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
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 [this message]
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=E16cz0J-0000yQ-00@starship.berlin \
--to=phillips@bonn-fries.net \
--cc=akpm@zip.com.au \
--cc=dmccr@us.ibm.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=manfred@colorfullife.com \
--cc=mingo@redhat.co \
--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