linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
	Andrea Arcangeli <arcangeli@mbox.queen.it>,
	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: Wed, 8 Jul 1998 23:11:11 +0100	[thread overview]
Message-ID: <199807082211.XAA14327@dax.dcs.ed.ac.uk> (raw)
In-Reply-To: <Pine.LNX.3.96.980708205506.15562A-100000@mirkwood.dummy.home>

Hi,

On Wed, 8 Jul 1998 20:57:27 +0200 (CEST), Rik van Riel
<H.H.vanRiel@phys.uu.nl> said:

> When my zone allocator is finished, it'll be a piece of
> cake to implement lazy page reclamation.

I've already got a working implementation.  The issue of lazy
reclamation is pretty much independent of the allocator underneath; I
don't see it being at all hard to run the lazy reclamation stuff on top
of any form of zoned allocation.

> With lazy reclamation, we simply place an upper limit
> on the number of _active_ pages. A process that's really
> thrashing away will simply be moving it's pages to/from
> the inactive list.

Exactly.  We _do_ want to be able to increase the RSS limit dynamically
to avoid moving too many pages in and out of the working set, but if the
process's working set is _that_ large, then performance will be
dominated so much by L2 cache trashing and CPU TLB misses that the extra
minor page faults we'd get are unlikely to be a catastrophic performance
problem.  

In short, if there's no contention on memory, there's no need to impose
RSS limits at all: it's just an extra performance cost.  But as soon as
physical memory contention becomes important, the RSS management is an
obvious way of restricting the performance impact of the large processes
on the rest of the system.

> And when memory pressure increases, other processes will
> start taking pages away from the inactive pages collection
> of our memory hog.

Precisely. 

> That looks quite OK to me...

Yep.  That's one of the main motivations behind the swap cache work in
2.1: the way the swapper now works, we can unhook pages from the
process's page tables and send them to swap once the RSS limit is
exceeded, but keep a copy of those pages in the swap cache so that if
the process wants a page back before we've got around to reusing the
memory, it's just a minor fault to bring it back in.  All of this code
is already present in 2.1 now.  The only thing missing is the
maintenance of the LRU list of lazy pages for reuse.

--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-08 22:13 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
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 [this message]
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=199807082211.XAA14327@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