linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Rik van Riel <riel@conectiva.com.br>,
	"Stephen C. Tweedie" <sct@redhat.com>,
	Marcelo Tosatti <marcelo@conectiva.com.br>,
	Jens Axboe <axboe@suse.de>, Alan Cox <alan@redhat.com>,
	Derek Martin <derek@cerberus.ne.mediaone.net>,
	Linux Kernel <linux-kernel@vger.rutgers.edu>,
	linux-mm@kvack.org, "David S. Miller" <davem@redhat.com>
Subject: Re: [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on 2.4.0-test2
Date: Fri, 14 Jul 2000 10:01:06 +0100	[thread overview]
Message-ID: <20000714100106.C3113@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0007111955100.5098-100000@inspiron.random>; from andrea@suse.de on Tue, Jul 11, 2000 at 08:00:23PM +0200

Hi,

On Tue, Jul 11, 2000 at 08:00:23PM +0200, Andrea Arcangeli wrote:
> 
> So tell me how with your design can I avoid the kernel to unmap anything
> while running:
> 
> 	cp /dev/zero .

Because the unmapped cache pages from the ./zero output file are on
the inactive queue.  We refill the scavenge queue from that inactive
queue.  Only once there are too few inactive pages will we do _any_
aging of active pages.

You are still left with the "cp /dev/zero ." command flushing other
unmapped pages out of cache, of course, but nothing mapped needs to
get unmapped.

Actually it's likely to be a bit more complex than this, because there
is memory pressure on the inactive queue in this case, so it _will_
grow initially until the write throttling achieves an equilibrium.
That's fine, because we really don't want a machine with zero memory
in cache to become unable to cache anything simply because it refuses
ever to swap out.

However, there's a second thing Rik and I were talking about relating
to this problem --- if there is constant memory pressure on the
inactive queue, we *want* to do a small amount of background page
aging.  Any mapped pages which are still in use, even if they are only
being used infrequently, should still end up being marked referenced.
Pages which are just not being touched can, and should, be swapped
eventually.

The trouble is that the kernel can't easily tell the difference
between the read of a cd image and the read of a compiler header file
just from the file access alone.  If we don't have enough cache to
cache the whole set of header files that the compiler is using, then
obviously (1) we never see multiple cache hits, because the data is
evicted from cache before the application requests it again; but also
(2) we _want_ to be able to increase the cache in this case, even at
the expense of swappinng out other inactive processes.

The only way you can detect the "other inactive processes" (or at
least inactive pages) is to have background page aging going on while
you have memory pressure in the cache.

Cheers,
 Stephen
--
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.eu.org/Linux-MM/

  parent reply	other threads:[~2000-07-14  9:01 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20000629114407.A3914@redhat.com>
     [not found] ` <Pine.LNX.4.21.0006291330520.1713-100000@inspiron.random>
2000-06-29 13:00   ` Stephen C. Tweedie
2000-07-06 10:35     ` Andrea Arcangeli
2000-07-06 13:29       ` Stephen C. Tweedie
2000-07-09 17:11         ` Swap clustering with new VM Marcelo Tosatti
2000-07-09 20:53           ` Andrea Arcangeli
2000-07-11  9:36             ` Stephen C. Tweedie
2000-07-09 20:31         ` [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on 2.4.0-test2 Andrea Arcangeli
2000-07-11 11:50           ` Stephen C. Tweedie
2000-07-11 16:17             ` Andrea Arcangeli
2000-07-11 16:36               ` Juan J. Quintela
2000-07-11 17:33                 ` Andrea Arcangeli
2000-07-11 17:45                   ` Rik van Riel
2000-07-11 17:54                     ` Andrea Arcangeli
2000-07-11 18:03                       ` Juan J. Quintela
2000-07-11 19:32                         ` Andrea Arcangeli
2000-07-12  0:05                           ` John Alvord
2000-07-12  0:52                             ` Andrea Arcangeli
2000-07-12 18:02                             ` Rik van Riel
2000-07-14  8:51               ` Stephen C. Tweedie
2000-07-11 17:32           ` Rik van Riel
2000-07-11 17:41             ` Andrea Arcangeli
2000-07-11 17:47               ` Rik van Riel
2000-07-11 18:00                 ` Andrea Arcangeli
2000-07-11 18:06                   ` Rik van Riel
2000-07-17  7:09                     ` [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on Yannis Smaragdakis
2000-07-17  9:28                       ` Stephen C. Tweedie
2000-07-17 13:01                         ` James Manning
2000-07-17 14:32                           ` Scott F. Kaplan
2000-07-17 14:53                         ` Rik van Riel
2000-07-17 16:44                           ` Manfred Spraul
2000-07-17 17:02                             ` Rik van Riel
2000-07-17 18:55                           ` Yannis Smaragdakis
2000-07-17 19:57                           ` John Fremlin
2000-07-17 14:46                       ` Alan Cox
2000-07-17 14:55                         ` Scott F. Kaplan
2000-07-17 15:31                           ` Rik van Riel
2000-07-14  9:01                   ` Stephen C. Tweedie [this message]
2000-07-11 18:13               ` [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on 2.4.0-test2 Juan J. Quintela
2000-07-11 20:57                 ` Roger Larsson
2000-07-11 22:49                   ` Juan J. Quintela
2000-07-12 16:01               ` Kev
2000-07-06 13:54       ` [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on2.4.0-test2 Roman Zippel

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=20000714100106.C3113@redhat.com \
    --to=sct@redhat.com \
    --cc=alan@redhat.com \
    --cc=andrea@suse.de \
    --cc=axboe@suse.de \
    --cc=davem@redhat.com \
    --cc=derek@cerberus.ne.mediaone.net \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=marcelo@conectiva.com.br \
    --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