From: "Stephen C. Tweedie" <sct@redhat.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
george anzinger <george@mvista.com>,
Alexander Viro <viro@math.psu.edu>,
linux-mm@kvack.org, bcrl@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: changing mm->mmap_sem (was: Re: system call for process information?)
Date: Fri, 16 Mar 2001 12:53:38 +0000 [thread overview]
Message-ID: <20010316125338.L30889@redhat.com> (raw)
In-Reply-To: <20010316094918.F30889@redhat.com> <Pine.LNX.4.21.0103160844300.5790-100000@imladris.rielhome.conectiva>
In-Reply-To: <Pine.LNX.4.21.0103160844300.5790-100000@imladris.rielhome.conectiva>; from riel@conectiva.com.br on Fri, Mar 16, 2001 at 08:50:25AM -0300
Hi,
On Fri, Mar 16, 2001 at 08:50:25AM -0300, Rik van Riel wrote:
> On Fri, 16 Mar 2001, Stephen C. Tweedie wrote:
>
> > > Write locks would be used in the code where we actually want
> > > to change the VMA list and page faults would use an extra lock
> > > to protect against each other (possibly a per-pagetable lock
> >
> > Why do we need another lock? The critical section where we do the
> > final update on the pte _already_ takes the page table spinlock to
> > avoid races against the swapper.
>
> The problem is that mmap_sem seems to be protecting the list
> of VMAs, so taking _only_ the page_table_lock could let a VMA
> change under us while a page fault is underway ...
Right, I'm not suggesting removing that: making the mmap_sem
read/write is fine, but yes, we still need that semaphore. But as for
the "page faults would use an extra lock to protect against each
other" bit --- we already have another lock, the page table lock,
which can be used in this way, so ANOTHER lock should be unnecessary.
--Stephen
WARNING: multiple messages have this Message-ID (diff)
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
george anzinger <george@mvista.com>,
Alexander Viro <viro@math.psu.edu>,
linux-mm@kvack.org, bcrl@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: changing mm->mmap_sem (was: Re: system call for process information?)
Date: Fri, 16 Mar 2001 12:53:38 +0000 [thread overview]
Message-ID: <20010316125338.L30889@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0103160844300.5790-100000@imladris.rielhome.conectiva>; from riel@conectiva.com.br on Fri, Mar 16, 2001 at 08:50:25AM -0300
Hi,
On Fri, Mar 16, 2001 at 08:50:25AM -0300, Rik van Riel wrote:
> On Fri, 16 Mar 2001, Stephen C. Tweedie wrote:
>
> > > Write locks would be used in the code where we actually want
> > > to change the VMA list and page faults would use an extra lock
> > > to protect against each other (possibly a per-pagetable lock
> >
> > Why do we need another lock? The critical section where we do the
> > final update on the pte _already_ takes the page table spinlock to
> > avoid races against the swapper.
>
> The problem is that mmap_sem seems to be protecting the list
> of VMAs, so taking _only_ the page_table_lock could let a VMA
> change under us while a page fault is underway ...
Right, I'm not suggesting removing that: making the mmap_sem
read/write is fine, but yes, we still need that semaphore. But as for
the "page faults would use an extra lock to protect against each
other" bit --- we already have another lock, the page table lock,
which can be used in this way, so ANOTHER lock should be unnecessary.
--Stephen
--
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:[~2001-03-16 20:47 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-12 17:08 system call for process information? Guennadi Liakhovetski
2001-03-12 18:27 ` Alexander Viro
2001-03-12 21:21 ` Guennadi Liakhovetski
2001-03-13 2:56 ` Nathan Paul Simons
2001-03-13 3:20 ` Alexander Viro
2001-03-13 9:55 ` Guennadi Liakhovetski
2001-03-13 21:05 ` Albert D. Cahalan
2001-03-13 22:02 ` Nathan Paul Simons
2001-03-13 22:50 ` Albert D. Cahalan
2001-03-13 22:52 ` Rik van Riel
2001-03-14 1:53 ` Martin Dalecki
2001-03-14 2:28 ` Rik van Riel
2001-03-14 8:24 ` george anzinger
2001-03-14 19:19 ` Rik van Riel
2001-03-14 16:27 ` george anzinger
2001-03-15 12:24 ` changing mm->mmap_sem (was: Re: system call for process information?) Rik van Riel
2001-03-15 12:24 ` Rik van Riel
2001-03-16 9:49 ` Stephen C. Tweedie
2001-03-16 9:49 ` Stephen C. Tweedie
2001-03-16 11:50 ` Rik van Riel
2001-03-16 11:50 ` Rik van Riel
2001-03-16 12:53 ` Stephen C. Tweedie [this message]
2001-03-16 12:53 ` Stephen C. Tweedie
2001-03-18 7:23 ` Rik van Riel
2001-03-18 7:23 ` Rik van Riel
2001-03-18 9:56 ` Mike Galbraith
2001-03-18 9:56 ` Mike Galbraith
2001-03-18 10:46 ` Rik van Riel
2001-03-18 10:46 ` Rik van Riel
2001-03-18 12:33 ` Mike Galbraith
2001-03-18 12:33 ` Mike Galbraith
2001-03-14 1:59 ` system call for process information? john slee
2001-03-14 19:53 ` Szabolcs Szakacsits
2001-03-14 19:55 ` Alexander Viro
2001-03-14 20:23 ` Szabolcs Szakacsits
2001-03-14 20:21 ` Alexander Viro
-- strict thread matches above, loose matches on Subject: below --
2001-03-18 9:34 changing mm->mmap_sem (was: Re: system call for process information?) Manfred Spraul
2001-03-18 10:56 ` Rik van Riel
2001-03-19 12:54 ` Stephen C. Tweedie
[not found] <Pine.LNX.4.33.0103181407520.1426-100000@mikeg.weiden.de>
2001-03-18 14:43 ` Rik van Riel
2001-03-18 14:43 ` Rik van Riel
2001-03-18 18:13 ` Linus Torvalds
[not found] <200103181813.KAA22153@penguin.transmeta.com>
2001-03-18 20:59 ` Rik van Riel
2001-03-19 1:21 ` Linus Torvalds
2001-03-19 2:59 ` Rik van Riel
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=20010316125338.L30889@redhat.com \
--to=sct@redhat.com \
--cc=bcrl@redhat.com \
--cc=george@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@conectiva.com.br \
--cc=viro@math.psu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.