linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Gould <dg@suse.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Marcelo Tosatti <marcelo@conectiva.com.br>,
	"Stephen C. Tweedie" <sct@redhat.com>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH] vma limited swapin readahead
Date: Wed, 31 Jan 2001 16:24:24 -0800	[thread overview]
Message-ID: <20010131162424.E9053@archimedes.oak.suse.com> (raw)
In-Reply-To: <m18znrcxx7.fsf@frodo.biederman.org>; from ebiederm@xmission.com on Wed, Jan 31, 2001 at 12:40:52PM -0700

On Wed, Jan 31, 2001 at 12:40:52PM -0700, Eric W. Biederman wrote:
> Marcelo Tosatti <marcelo@conectiva.com.br> writes:
> > On Wed, 31 Jan 2001, Stephen C. Tweedie wrote:
> > > On Wed, Jan 31, 2001 at 01:05:02AM -0200, Marcelo Tosatti wrote:
> > > > 
> > > > However, the pages which are contiguous on swap are not necessarily
> > > > contiguous in the virtual memory area where the fault happened. That means
> > > > the swapin readahead code may read pages which are not related to the
> > > > process which suffered a page fault.
> > > > 
> > > Yes, but reading extra sectors is cheap, and throwing the pages out of
> > > memory again if they turn out not to be needed is also cheap.  The
> > > on-disk swapped pages are likely to have been swapped out at roughly
> > > the same time, which is at least a modest indicator of being of the
> > > same age and likely to have been in use at the same time in the past.
> > 
> > You're throwing away pages from memory to do the readahead. 
> > 
> > This pages might be more useful than the pages which you're reading from
> > swap. 
> 
> Possibly.  However the win (lower latency) from getting swapin
> readahead is probably even bigger.  And you are throwing out the least
> desirable pages in memory.
> 
> > > I'd like to see at lest some basic performance numbers on this,
> > > though.
> > 
> > I'm not sure if limiting the readahead the way my patch does is a better
> > choice, too.
... 
> Unless you can see a big performance win somewhere please don't submit
> this to Linus for inclusion.

Hmmm, arguably reading pages we do not want is a mistake. I should think that
if a big performance win is required to justify a design choice, it should
be especially required to show such a win for doing something that on its
face is wrong.

I am skeptical of the argument that we can win by replacing "the least
desirable" pages with pages were even less desireable and that we have
no recent indication of any need for. It seems possible under heavy swap
to discard quite a portion of the useful pages in favor of junk that just
happenned to have a lucky disk address.

-dg

-- 
David Gould                                                 dg@suse.com
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
You left them alone in a room with a penguin?!  Mr Gates, your men are
already dead.
--
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/

  reply	other threads:[~2001-02-01  0:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-31  3:05 Marcelo Tosatti
2001-01-31 10:21 ` Stephen C. Tweedie
2001-01-31  8:40   ` Marcelo Tosatti
2001-01-31 19:40     ` Eric W. Biederman
2001-02-01  0:24       ` David Gould [this message]
2001-02-01  7:41         ` Eric W. Biederman
2001-02-01 11:26         ` Stephen C. Tweedie
2001-02-01 10:53           ` Marcelo Tosatti
2001-02-01 14:36             ` Stephen C. Tweedie
2001-02-01 16:45               ` Rik van Riel
2001-02-01 17:20                 ` Ingo Oeser
2001-02-01 17:54                   ` Rik van Riel
2001-02-01 17:27                 ` Stephen C. Tweedie
2001-02-01 18:59           ` David Gould
2001-02-01 19:07             ` Rik van Riel

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=20010131162424.E9053@archimedes.oak.suse.com \
    --to=dg@suse.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=marcelo@conectiva.com.br \
    --cc=sct@redhat.com \
    /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