From: Andi Kleen <andi@firstfloor.org>
To: hamid.jahanjou@gmail.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] VM: Implements the swap-out page-clustering technique
Date: Fri, 05 Sep 2008 11:19:38 +0200 [thread overview]
Message-ID: <87iqtbuez9.fsf@basil.nowhere.org> (raw)
In-Reply-To: <48BFCECE.90103@gmail.com> (Hamid R. Jahanjou's message of "Thu, 04 Sep 2008 15:34:30 +0330")
"Hamid R. Jahanjou" <hamid.jahanjou@gmail.com> writes:
> From: Hamid R. Jahanjou
>
> Implements the idea of swap-out page clustering from *BSD for
> Linux. Each time a candidate page is to be swapped out,
> virtually-nearby pages are scanned to find eligible pages to be
> swapped out too as a cluster. This technique increases the likelihood of
> bringing in related data on a page fault and decreases swap space
> fragmentation in the long run. Currently, Linux searches only
> physically-nearby pages which is not optimal since, over time, physically-
> adjacent pages may become unrelated.
>
> The code can be statically tuned. No benchmarks. I'm not sure whether
> the added complexity is acceptable.
Just some general comments:
First I think virtual swap clustering is a great idea in theory and
long overdue. Hopefully the numbers will agree.
In general the code would be much nicer if you didn't pass around
all that much in a structure (which is just a fancy way to have
a function with lots of arguments) Perhaps try to restructure
it a bit to make this smaller? Ideally clustering_info should disappear
or at least get much smaller.
Then continue_search seems to be only set to one value so it
can be eliminated? Perhaps there is more like this.
I didn't quite understand the "adjust the value of our search by
the allocation order". The allocation order should be normally 0.
I think having a tunable for the cluster sizes would be a good idea.
At some point they might be even device dependent (e.g. on a flash
device you would like to have them roughly erase block sized)
-Andi
--
ak@linux.intel.com
next prev parent reply other threads:[~2008-09-05 9:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-04 12:04 [PATCH] VM: Implements the swap-out page-clustering technique Hamid R. Jahanjou
2008-09-04 23:14 ` Rik van Riel
2008-09-04 23:14 ` Andrew Morton
2008-09-05 7:45 ` Hamid R. Jahanjou
2008-09-05 6:58 ` Andrew Morton
2008-09-05 9:19 ` Andi Kleen [this message]
2008-09-05 20:27 ` Hamid R. Jahanjou
2008-09-05 19:45 ` Andi Kleen
2008-09-06 5:42 ` Rik van Riel
2008-09-08 0:28 ` Zan Lynx
2008-09-08 0:55 ` Rik van Riel
2008-09-10 8:16 ` Hamid R. Jahanjou
2008-09-10 17:08 ` Ray Lee
2008-09-10 17:39 ` Rik van Riel
2008-09-08 3:50 ` Li Yu
2008-09-08 9:51 ` hamidreza jahanjou
[not found] ` <48C4FECF.2000708@gmail.com>
2008-09-08 10:31 ` Li Yu
2008-09-24 13:56 ` Luiz Fernando N. Capitulino
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=87iqtbuez9.fsf@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=hamid.jahanjou@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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.