From: jfm2@club-internet.fr
To: sct@redhat.com
Cc: jfm2@club-internet.fr, linux-mm@kvack.org
Subject: Re: Two naive questions and a suggestion
Date: 23 Nov 1998 21:59:33 -0000 [thread overview]
Message-ID: <19981123215933.2401.qmail@sidney.remcomp.fr> (raw)
In-Reply-To: <199811231808.SAA21383@dax.scot.redhat.com> (sct@redhat.com)
>
> Hi,
>
> On 19 Nov 1998 00:20:37 -0000, jfm2@club-internet.fr said:
>
> > 1) Is there any text describing memory management in 2.1? (Forgive me
> > if I missed an obvious URL)
>
> The source code. :)
>
I knew about it. :) And this is not an URL :)
> > 2) Are there plans for implementing the swapping of whole processes a
> > la BSD?
>
> Not exactly, but there are substantial plans for other related changes.
> In particular, most of the benefits of BSD-style swapping can be
> achieved through swapping of page tables, dynamic RSS limits and
> streaming swapout, all of which are on the slate for 2.3.
>
The problem is: will you be able to manage the following situation?
Two processes running in an 8 Meg box. Both will page fault every ms
if you give them 4 Megs (they are scanning large arrays so no
locality), a page fault will take 20 ms to handle. That means only 5%
of the CPU time is used, remainder is spent waiting for page being
brought from disk or pushing a page of the other process out of
memory. And both of these processes would run like hell (no page
fault) given 6 Megs of memory.
Only solution I see is stop one of them (short of adding memory :) and
let the other one make some progress. That is swapping. Of course
swapping can be undesiarable in work stations and that is the reason I
suggested user control about MM policy be it by recompiling, by /proc
or by module insertion.
In 96 I asked for that same feature, gave the same example (same
numbers :-) and Alan Cox agreed but told Linux was not used under
heavy loads. That means we are in a catch 22 situation: Linux not used
for heavy loads because it does not handle them well and the necessary
feaatures not implemented because it is not used in such situations.
And now we are at it: in 2.0 I found a deamon can be killed by the
system if it runs out of VM. Problem is: it was a normal user process
who had allocatedc most of it and in addition that daemon could be
important enough it is better to kill anything else, so it would be
useful to give some privilege to root processes here.
I think this ends my Christmas wish list. :)
--
Jean Francois Martinez
Project Independence: Linux for the Masses
http://www.independence.seul.org
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
next prev parent reply other threads:[~1998-11-23 23:55 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-11-19 0:20 jfm2
1998-11-19 20:05 ` Rik van Riel
1998-11-20 1:25 ` jfm2
1998-11-20 15:31 ` Eric W. Biederman
1998-11-23 18:08 ` Stephen C. Tweedie
1998-11-23 20:45 ` jfm2
1998-11-23 21:59 ` jfm2 [this message]
1998-11-24 1:21 ` Vladimir Dergachev
1998-11-24 11:17 ` Stephen C. Tweedie
1998-11-24 21:44 ` jfm2
1998-11-25 6:41 ` Rik van Riel
1998-11-25 12:27 ` Stephen C. Tweedie
1998-11-25 13:08 ` Rik van Riel
1998-11-25 14:46 ` Stephen C. Tweedie
1998-11-25 16:47 ` Rik van Riel
1998-11-25 21:02 ` Stephen C. Tweedie
1998-11-25 21:21 ` Rik van Riel
1998-11-25 22:29 ` Stephen C. Tweedie
1998-11-26 7:30 ` Rik van Riel
1998-11-26 12:48 ` Stephen C. Tweedie
1998-11-25 20:01 ` jfm2
1998-11-26 7:16 ` Rik van Riel
1998-11-26 19:59 ` jfm2
1998-11-27 17:45 ` Stephen C. Tweedie
1998-11-27 21:14 ` jfm2
1998-11-25 14:48 ` Eric W. Biederman
1998-11-25 20:29 ` jfm2
1998-11-25 16:31 ` ralf
1998-11-26 12:18 ` 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=19981123215933.2401.qmail@sidney.remcomp.fr \
--to=jfm2@club-internet.fr \
--cc=linux-mm@kvack.org \
--cc=sct@redhat.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