From: Rajagopal Ananthanarayanan <ananth@sgi.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: linux-mm@kvack.org
Subject: Re: Odd swap behavior
Date: Wed, 04 Oct 2000 16:03:33 -0700 [thread overview]
Message-ID: <39DBB745.7D652E4E@sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0010041909570.1054-100000@duckman.distro.conectiva>
Rik van Riel wrote:
> > Does that mean stack pages of processes are not included?
> > Non-aggressive swap can hurt performance.
>
> I don't really see a clean way to do that in 2.4 ...
We can perhaps talk about this at the Storage Workshop ...
[ ... ]
> > Would it not be more efficient to bung clean (read) pages directly
> > to inactive_clean on age = 0?
>
> I don't know if this would make any difference...
I think it would. Consider steady state where pages
are all "in use". Any new allocation has to start with
pushing a page from active -> inactive, and then
inactive -> inactive_clean, if necessary, and then reclaim.
Now, if we had pages which _are_ clean, then the path taken
is simply active -> inactive_clean -> reclaim.
>
> And in fact, I'm contemplating adding /all/ pages
> that are deactivated to the inactive_dirty list,
> since that way we'll reclaim all inactive pages
> in FIFO order.
>
> Currently we may "skip" some pages that were put
> on the inactive_dirty list but were cleaned up
> subsequently because we can find enough active
> pages that can be moved to the inactive_clean
> list immediately ...
>
This is an interesting idea, although it seems
antithetical to what I said above. I think pure
FIFO has its merits in accomodating longer locality of
reference; it can help dbench.
If you have a patch (to always deactivate to inactive_dirty),
I can help you gauge it with the benchmarks ...
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------
--
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/
next prev parent reply other threads:[~2000-10-04 23:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-04 0:23 Rajagopal Ananthanarayanan
2000-10-04 15:14 ` Rik van Riel
2000-10-04 21:39 ` Rajagopal Ananthanarayanan
2000-10-04 21:46 ` Rik van Riel
2000-10-04 22:05 ` Rajagopal Ananthanarayanan
2000-10-04 22:13 ` Rik van Riel
2000-10-04 23:03 ` Rajagopal Ananthanarayanan [this message]
2000-10-05 0:07 ` Rik van Riel
2000-10-05 2:31 ` Rajagopal Ananthanarayanan
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=39DBB745.7D652E4E@sgi.com \
--to=ananth@sgi.com \
--cc=linux-mm@kvack.org \
--cc=riel@conectiva.com.br \
/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