linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Gould <dg@suse.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: 01 Feb 2001 00:41:12 -0700	[thread overview]
Message-ID: <m14ryedf53.fsf@frodo.biederman.org> (raw)
In-Reply-To: David Gould's message of "Wed, 31 Jan 2001 16:24:24 -0800"

David Gould <dg@suse.com> writes:

> 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.

The case for files and has already been justified.   
The performance gain of reading pages that are contiguous on disk has
been justified. 
The only problem thing that has not been shown is that swap pages that
are used together are located near each other in swap.

As for design choices simplicity, maintainability and
comprehensiblility, tend to be more important than absolute
performance.  This lets bugs be fixed, and the big changes that tend
to be the biggest wins happen.

> 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.

I won't argue that.  My gut just says we should work to improve the
disk addresses, so it isn't luck. ;)  And only if we fail in that
hack up the efficient simple policy, that we have for reading disk
data in.

Of course since I'm not actually writing the code at the moment
this is all hot air :)

Eric

--
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  7:41 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
2001-02-01  7:41         ` Eric W. Biederman [this message]
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=m14ryedf53.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=dg@suse.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