linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mark_H_Johnson@Raytheon.com
To: Nick Piggin <piggin@cyberone.com.au>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	mfedyk@matchmail.com, 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 08:18:15 -0600	[thread overview]
Message-ID: <OF9DC8F5B1.0044A21E-ON86256E55.004DF368@raytheon.com> (raw)




Nick Piggin <piggin@cyberone.com.au> wrote:
>Andrew Morton wrote:

>>That effect is to cause the whole world to be swapped out when people
>>return to their machines in the morning.  Once they're swapped back in
the
>>first thing they do it send bitchy emails to you know who.
>>
>>>From a performance perspective it's the right thing to do, but nobody
likes
>>it.
>>
>>
>
>Yeah. I wonder if there is a way to be smarter about dropping these
>used once pages without putting pressure on more permanent pages...
>I guess all heuristics will fall down somewhere or other.

Just a question, but I remember from VMS a long time ago that
as part of the working set limits, the "free list" was used to keep
pages that could be freely used but could be put back into the working
set quite easily (a "fast" page fault). Could you keep track of the
swapped pages in a similar manner so you don't have to go to disk to
get these pages [or is this already being done]? You would pull them
back from the free list and avoid the disk I/O in the morning.

By the way - with 2.4.24 I see a similar behavior anyway [slow to get
going in the morning]. I believe it is due to our nightly backup walking
through the disks. If you could FIX the retention of sequentially read
disk blocks from the various caches - that would help a lot more in
my mind.

--Mark H Johnson
  <mailto:Mark_H_Johnson@raytheon.com>

--
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 14:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-12 14:18 Mark_H_Johnson [this message]
2004-03-12 14:27 ` Nick Piggin
2004-03-12 19:46   ` Jamie Lokier
  -- strict thread matches above, loose matches on Subject: below --
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
2004-03-12 22:36         ` Mike Fedyk
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=OF9DC8F5B1.0044A21E-ON86256E55.004DF368@raytheon.com \
    --to=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