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: Tue, 7 Jul 1998 13:01:11 +0100	[thread overview]
Message-ID: <199807071201.NAA00934@dax.dcs.ed.ac.uk> (raw)
In-Reply-To: <Pine.LNX.3.96.980706203947.369E-100000@dragon.bogus>

Hi,

On Mon, 6 Jul 1998 21:28:42 +0200 (CEST), Andrea Arcangeli
<arcangeli@mbox.queen.it> said:

> On Mon, 6 Jul 1998, Stephen C. Tweedie wrote:
>> 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.

> Nice! The problem is that probably the kernel think that bash and every
> not 100% CPU eater is an idle process... 

Not at all. :) A process only has to touch a page once per sweep of
the vm scanner for that page to be marked in use.  A shell which
touches a few pages for every keystroke will get the same preservation
of those pages as a process which is touching the same number of pages
in a tight loop.

>> 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

> This is again more true for low memory machines (where the current kswapd
> policy sucks). I 100% agree with this, I don' t agree to swapout to make
> space from the cache. 

I've just explained why we _do_ want to do this on low memory
machines, to a certain extent.  When memory is low, we don't want to
keep around anything which we don't need,  and so swapping out
completely unused pages is a good thing.  The thing we need to avoid
is swapping anything touched recently; switching off swapout completely,
even just to make room for the cache, is wrong.

>> 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.

> I think that we are too much aggressive. 

Sure, in 2.1.

> It would be nice if it would be swapped out _only_ pages that are not used
> in the past half an hour. If kswapd would run in such way I would thank
> you a lot instead of being irritate ;-).

?? Some people will want to keep anything used within the last half
hour; in other cases, 5 minutes idle should qualify for a swapout.  On
the compilation benchmarks I run on 6MB machines, any page not used
within the past 10 seconds or so should be history!

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

> NO. I want lpd sitting around if it' s been used in the last 10 minutes
> for example. I don' t want to swapout process for make space for the
> _cache_ if the process is not 100% idle instead.

Not if your memory is full.

You CANNOT say "I want this in memory, not that".  You will always be
able to find situations where it doesn't work.  You need a balance.
I'm quite sure that you don't want your kernel build to thrash simply
because the vm system is afraid of swapping out the sendmail and lpd
daemons you used 10 minutes ago.

> 2.0.34 destroy (wooo nice I love when I see the cache destroyed ;-)
> completly the cache and runs great. 

No it doesn't.  It balances the cache better; that's a very different
thing.  The only difference between 2.0 and 2.1 in this regard is the
tuning of that balance; the underlying code is more or less the same.

--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-07 15:12 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
1998-07-06 19:28             ` Andrea Arcangeli
1998-07-07 12:01               ` Stephen C. Tweedie [this message]
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=199807071201.NAA00934@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