linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Andrea Arcangeli <arcangeli@mbox.queen.it>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
	Rik van Riel <H.H.vanRiel@phys.uu.nl>,
	Linux MM <linux-mm@kvack.org>,
	Linux Kernel <linux-kernel@vger.rutgers.edu>
Subject: Re: cp file /dev/zero <-> cache [was Re: increasing page size]
Date: Mon, 6 Jul 1998 15:36:18 +0100	[thread overview]
Message-ID: <199807061436.PAA01547@dax.dcs.ed.ac.uk> (raw)
In-Reply-To: <Pine.LNX.3.96.980706142359.169A-100000@dragon.bogus>

Hi,

On Mon, 6 Jul 1998 14:34:02 +0200 (CEST), Andrea Arcangeli
<arcangeli@mbox.queen.it> said:

> On Mon, 6 Jul 1998, Stephen C. Tweedie wrote:
>> or 16MB box doing compilations, then you desperately want unused process
>> data pages --- idle bits of inetd, lpd, sendmail, init, the shell, the

> Now also the process that needs memory got swapped out.

No --- that's the whole point.  We have per-page process page aging
which lets us differentiate between processes which are active and those
which are idle, and between the used and unused pages within the active
processes.

If you are short on memory, then you don't want to keep around any
process pages which belong to idle tasks.  The only way to do that is to
invoke the swapper.  We need to make sure that we are just aggressive
enough to discard pages which are not in use, and not to discard pages
which have been touched recently.

If we simply prune the cache to zero before doing any swapping, then we
will be eliminating potentially useful data out of the cache instead of
throwing away pages to swap which may not have been used in the past
half an hour.  

That's what the balancing issue is about: if there are swap pages which
are not being touched at all and files such as header files which are
being constantly accessed, then we need to do at least _some_ swapping
to eliminate the idle process pages.

> I _really_ don' t want cache and readahead when the system needs
> memory. 

You also don't want lpd sitting around, either.

> The only important thing is to avoid the always swapin/out and provide
> free memory to the process. 

It's just wishful thinking to assume you can do this simply by
destroying the cache.  Oh, and you _do_ want readahead even with little
memory, otherwise you are doing 10 disk IOs to read a file instead of
one; and on a box which is starved of memory, that implies you'll
probably see a disk seek between each IO.  That's just going to thrash
your disk even harder.

> You don' t run in a 32Mbyte box I see ;-).

I run in 64MB,  16MB and 6MB for testing purposes.

--Stephen
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

  reply	other threads:[~1998-07-06 17:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.3.96.980705072829.17879D-100000@mirkwood.dummy.home>
1998-07-05 11:32 ` Andrea Arcangeli
1998-07-05 17:00   ` Rik van Riel
1998-07-05 18:38     ` Andrea Arcangeli
1998-07-05 19:31       ` Rik van Riel
1998-07-06 10:38         ` Stephen C. Tweedie
1998-07-06 11:42           ` Rik van Riel
1998-07-06 14:20         ` Andrea Arcangeli
1998-07-06 10:31       ` Stephen C. Tweedie
1998-07-06 12:34         ` Andrea Arcangeli
1998-07-06 14:36           ` Stephen C. Tweedie [this message]
1998-07-06 19:28             ` Andrea Arcangeli
1998-07-07 12:01               ` Stephen C. Tweedie
1998-07-07 15:54                 ` Rik van Riel
1998-07-07 17:32                   ` Benjamin C.R. LaHaise
1998-07-08 13:54                     ` Stephen C. Tweedie
1998-07-08 21:19                       ` Andrea Arcangeli
1998-07-11 11:18                         ` Rik van Riel
1998-07-11 21:11                           ` Stephen C. Tweedie
1998-07-08 13:45                   ` Stephen C. Tweedie
1998-07-08 18:57                     ` Rik van Riel
1998-07-08 22:11                       ` Stephen C. Tweedie
1998-07-09  7:43                         ` Rik van Riel
1998-07-09 20:39                         ` Rik van Riel
1998-07-13 11:54                           ` Stephen C. Tweedie
1998-07-05 18:57     ` MOLNAR Ingo
1998-07-06 10:24     ` Stephen C. Tweedie
1998-07-06 13:37       ` Eric W. Biederman
1998-07-07 12:35         ` Stephen C. Tweedie
1998-07-09 13:01 Zachary Amsden
     [not found] <199807091442.PAA01020@dax.dcs.ed.ac.uk>
1998-07-09 18:59 ` Rik van Riel
1998-07-09 23:37   ` Stephen C. Tweedie
1998-07-10  5:57     ` Rik van Riel
1998-07-11 14:14 ` Rik van Riel
1998-07-11 21:23   ` Stephen C. Tweedie
1998-07-11 22:25     ` Rik van Riel
1998-07-13 13:23       ` Stephen C. Tweedie
1998-07-12  1:47     ` Benjamin C.R. LaHaise
1998-07-13 13:42       ` Stephen C. Tweedie
1998-07-18 22:10         ` Rik van Riel
1998-07-20 16:04           ` Stephen C. Tweedie

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=199807061436.PAA01547@dax.dcs.ed.ac.uk \
    --to=sct@redhat.com \
    --cc=H.H.vanRiel@phys.uu.nl \
    --cc=arcangeli@mbox.queen.it \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    /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