From: Rik van Riel <riel@conectiva.com.br>
To: Martin Dalecki <dalecki@evision-ventures.com>
Cc: "Albert D. Cahalan" <acahalan@cs.uml.edu>,
npsimons@fsmlabs.com,
Guennadi Liakhovetski <g.liakhovetski@ragingbull.com>,
Alexander Viro <viro@math.psu.edu>,
linux-kernel@vger.kernel.org
Subject: Re: system call for process information?
Date: Tue, 13 Mar 2001 23:28:00 -0300 (BRST) [thread overview]
Message-ID: <Pine.LNX.4.21.0103132325140.2056-100000@imladris.rielhome.conectiva> (raw)
In-Reply-To: <3AAECF17.727656A2@evision-ventures.com>
On Wed, 14 Mar 2001, Martin Dalecki wrote:
> Not the embedded folks!!! The server folks laugh histerically all
> times they go via ssh to a trashing busy box to see what's wrong and
> then they see top or ps auxe under linux never finishing they job:
That's a separate issue.
I guess the pagefault path should have _2_ locks.
One mmap_sem protecting read-only access to the address space
and another one for write access to the adress space (to stop
races with swapout, other page faults, ...).
At the point where the pagefault sleeps on IO, it could release
the read-only lock, so vmstat, top, etc can get the statistics
they need. Only during the time the pagefaulting code is actually
messing with the address space could it block read access (to
prevent others from seeing an inconsistent state).
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/
next prev parent reply other threads:[~2001-03-14 3:01 UTC|newest]
Thread overview: 29+ 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 [this message]
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-16 9:49 ` Stephen C. Tweedie
2001-03-16 11:50 ` Rik van Riel
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
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
2001-03-13 12:17 Rajiv Majumdar
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.0103132325140.2056-100000@imladris.rielhome.conectiva \
--to=riel@conectiva.com.br \
--cc=acahalan@cs.uml.edu \
--cc=dalecki@evision-ventures.com \
--cc=g.liakhovetski@ragingbull.com \
--cc=linux-kernel@vger.kernel.org \
--cc=npsimons@fsmlabs.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;
as well as URLs for NNTP newsgroup(s).