From: ebiederm@xmission.com (Eric W. Biederman)
To: Rik van Riel <riel@conectiva.com.br>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Daniel Phillips <phillips@bonn-fries.net>,
Rob Fuller <rfuller@nsisoftware.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: broken VM in 2.4.10-pre9
Date: 21 Sep 2001 02:23:15 -0600 [thread overview]
Message-ID: <m1wv2t7y18.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.33L.0109192000050.19147-100000@imladris.rielhome.conectiva>
Rik van Riel <riel@conectiva.com.br> writes:
> On 19 Sep 2001, Eric W. Biederman wrote:
>
> > That added to the fact that last time someone ran the numbers linux
> > was considerably faster than the BSD for mm type operations when not
> > swapping. And this is the common case.
>
> Optimising the VM for not swapping sounds kind of like
> optimising your system for doing empty fork()/exec()/exit()
> loops ;)
Swapping is an important case. But 9 times out of 10 you are managing
memory in caches, and throwing unused pages into swap. You aren't busily
paging the data back an forth. But if I have to make a choice in
what kind of situation I want to take a performance hit, paging
approaching thrashing or a system whose working set size is well
within RAM. I'd rather take the hit in the system that is paging.
Further fast IPC + fork()/exec()/exit() that programmers can count on
leads to more robust programs. Because different pieces of the program
can live in different processes. One of the reasons for the stability
of unix is that it has always had a firewall between it's processes so
one bad pointer will not bring down the entire system.
Besides I also like to run a lot of shell scripts, which again stress
the fork()/exec()/exit() path.
So no I don't think keeping those paths fast is silly.
I also think that being able to get good memory usage information is
important. I know that reverse maps make that job easier. But just
because the make an important case easier to get write I don't think
reverse maps are a shoe in.
Eric
--
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:[~2001-09-21 8:23 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-17 15:40 Rob Fuller
2001-09-17 16:03 ` Eric W. Biederman
2001-09-19 9:45 ` Daniel Phillips
2001-09-19 19:45 ` Alan Cox
2001-09-19 21:03 ` Eric W. Biederman
2001-09-19 22:04 ` Alan Cox
2001-09-19 22:26 ` Eric W. Biederman
2001-09-19 23:05 ` Rik van Riel
2001-09-20 11:28 ` Daniel Phillips
2001-09-20 12:06 ` Rik van Riel
2001-09-21 8:13 ` Daniel Phillips
2001-09-21 12:10 ` Rik van Riel
2001-09-21 15:27 ` Jan Harkes
2001-09-22 7:09 ` Daniel Phillips
2001-09-25 11:04 ` Mike Fedyk
2001-09-20 12:57 ` Alan Cox
2001-09-20 13:40 ` Daniel Phillips
2001-09-24 22:50 ` Pavel Machek
2001-09-26 18:22 ` Marcelo Tosatti
2001-09-26 23:44 ` Pavel Machek
2001-09-27 13:52 ` Eric W. Biederman
2001-10-01 11:37 ` Marcelo Tosatti
2001-09-19 23:00 ` Rik van Riel
2001-09-21 8:23 ` Eric W. Biederman [this message]
2001-09-21 12:01 ` Rik van Riel
2001-09-22 2:14 ` Alexander Viro
2001-09-22 3:09 ` Rik van Riel
2001-09-19 21:37 ` Eric W. Biederman
2001-09-19 21:55 ` David S. Miller
2001-09-20 13:02 ` Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2001-09-19 22:15 Rob Fuller
2001-09-19 22:21 ` David S. Miller
2001-09-19 22:30 ` Alan Cox
2001-09-19 22:48 ` Eric W. Biederman
2001-09-19 22:51 ` Bryan O'Sullivan
[not found] <Pine.LNX.4.33L.0109161330000.9536-100000@imladris.rielhome.conectiva>
2001-09-17 8:06 ` Eric W. Biederman
2001-09-17 12:12 ` Rik van Riel
2001-09-17 15:45 ` Eric W. Biederman
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=m1wv2t7y18.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=phillips@bonn-fries.net \
--cc=rfuller@nsisoftware.com \
--cc=riel@conectiva.com.br \
/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