From: Rik van Riel <riel@conectiva.com.br>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: 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 08:50:25 -0300 (BRST) [thread overview]
Message-ID: <Pine.LNX.4.21.0103160844300.5790-100000@imladris.rielhome.conectiva> (raw)
In-Reply-To: <20010316094918.F30889@redhat.com>
On Fri, 16 Mar 2001, Stephen C. Tweedie wrote:
> On Thu, Mar 15, 2001 at 09:24:59AM -0300, Rik van Riel wrote:
> > On Wed, 14 Mar 2001, Rik van Riel wrote:
>
> > The mmap_sem is used in procfs to prevent the list of VMAs
> > from changing. In the page fault code it seems to be used
> > to prevent other page faults to happen at the same time with
> > the current page fault (and to prevent VMAs from changing
> > while a page fault is underway).
>
> The page table spinlock should be quite sufficient to let us avoid
> races in the page fault code.
> > 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 ...
Then again, I guess just making mmap_sem a R/W lock should fix
our problems ... and maybe even make it possible (in 2.5?) to
let multithreaded programs have pagefaults at the same time,
instead of having all threads queue up behind mmap_sem.
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
--
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 12:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.33.0103141618320.21132-100000@duckman.distro.conectiva>
2001-03-15 12:24 ` Rik van Riel
2001-03-16 9:49 ` Stephen C. Tweedie
2001-03-16 11:50 ` Rik van Riel [this message]
2001-03-16 12:53 ` Stephen C. Tweedie
2001-03-18 7:23 ` Rik van Riel
2001-03-18 9:56 ` Mike Galbraith
2001-03-18 10:46 ` Rik van Riel
2001-03-18 12:33 ` Mike Galbraith
[not found] <Pine.LNX.4.33.0103181407520.1426-100000@mikeg.weiden.de>
2001-03-18 14:43 ` 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=Pine.LNX.4.21.0103160844300.5790-100000@imladris.rielhome.conectiva \
--to=riel@conectiva.com.br \
--cc=bcrl@redhat.com \
--cc=george@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sct@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox