linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Mike Fedyk <mfedyk@matchmail.com>
Cc: Nick Piggin <piggin@cyberone.com.au>,
	Mark_H_Johnson@raytheon.com, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	m.c.p@wolk-project.de, owner-linux-mm@kvack.org, plate@gmx.tm
Subject: Re: [PATCH] 2.6.4-rc2-mm1: vm-split-active-lists
Date: Fri, 12 Mar 2004 22:21:39 +0000	[thread overview]
Message-ID: <20040312222139.GG18799@mail.shareable.org> (raw)
In-Reply-To: <405228DC.1010107@matchmail.com>

Mike Fedyk wrote:
> That would have other side benefits.  If the anon page matches (I'm not 
> calling it "!dirty" since that might have other semantics in the current 
> VM) what is in swap, it can be cleaned without performing any IO.  Also, 
>  suspending will have much less IO to perform before completion.

Exactly those sort of benefits.

Btw, When you say "You're saying all anon memory should become
swap_cache eventually" it's worth noting that there are benefits to
doing it the other way too: speculatively pulling in pages that are
thought likely to be good for interactive response, at the expense of
pages which have been used more recently, and must remain in RAM for a
short while while they are considered in use, but aren't ranked so
highly based on some interactivity heuristics.

I.e. fixing the "everything swapped out in the morning" problem by
having a long term slow rebalancing in favour of pages which seem to
be requested for interactive purposes, competing against the short
term balance of whichever pages have been used recently or are
predicted by short term readahead.

Both replicating RAM pages to swap, and replicating swap or
file-backed pages to RAM can be speculative and down slowly, over the
long term, and when there is little other activity or I/O.

-- Jamie
--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2004-03-12 22:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-12 15:00 Mark_H_Johnson
2004-03-12 15:13 ` Nick Piggin
2004-03-12 19:35   ` Jamie Lokier
2004-03-12 21:17     ` Mike Fedyk
2004-03-12 22:21       ` Jamie Lokier [this message]
2004-03-12 22:36         ` Mike Fedyk
  -- strict thread matches above, loose matches on Subject: below --
2004-03-12 14:18 Mark_H_Johnson
2004-03-12 14:27 ` Nick Piggin
2004-03-12 19:46   ` Jamie Lokier
2004-03-11  0:04 Nick Piggin
2004-03-11 17:25 ` Marc-Christian Petersen
2004-03-12  9:09   ` Nick Piggin
2004-03-12  9:27     ` Andrew Morton
2004-03-12  9:37       ` Nick Piggin

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=20040312222139.GG18799@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=Mark_H_Johnson@raytheon.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=m.c.p@wolk-project.de \
    --cc=mfedyk@matchmail.com \
    --cc=owner-linux-mm@kvack.org \
    --cc=piggin@cyberone.com.au \
    --cc=plate@gmx.tm \
    /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