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 Odd swap behavior 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.