From: Andi Kleen <andi@firstfloor.org>
To: "Hamid R. Jahanjou" <hamid.jahanjou@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] VM: Implements the swap-out page-clustering technique
Date: Fri, 5 Sep 2008 21:45:01 +0200 [thread overview]
Message-ID: <20080905194501.GZ18288@one.firstfloor.org> (raw)
In-Reply-To: <48C19648.8030002@gmail.com>
On Fri, Sep 05, 2008 at 11:57:52PM +0330, Hamid R. Jahanjou wrote:
> > 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.
> >
>
> Thanks for the review and the comments.
> Do you consider the clustering_info struct to hurt the readability
> of the code or there is some other technical reasons ?
It's a fancy way to have a function with lots of arguments
and having lots of arguments is typically a sign for a poor code
structure, with functions not being properly separated.
I know the standard scanner does it too, but it's also somewhat
poor there and especially there's no excuse for doing it in much
simpler code/
>
> > 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)
> >
>
> The allocation order value is initially passed to the try_to_free_pages()
Yes, but that has nothing to do in how much you should swap cluster.
AFAIK the main motivation for swap clustering is to avoid the extreme
seekiness that happens during swap in (that is the main reason
why swap on Linux often takes so long). And also to use the IO
device well. IO devices today typically have a "minimum useful
unit of IO" which is much larger than a page. Typically it's at least a
MB, sometimes even more e.g. on flash or on some RAID controllers.
Making it even larger is good to avoid seeks on read which are very
costly on spinning disks.
Also for user application swapping the order will be near always 0
(except for large page users, but that's really a exotic corner case today)
And clustering for one page doesn't make much sense.
So I don't think you should care about that order, but make it a
tunable and experiment what the best values are on different IO
devices and then possibly later make it dependent on the device.
-Andi
--
ak@linux.intel.com
next prev parent reply other threads:[~2008-09-05 19:41 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
2008-09-05 20:27 ` Hamid R. Jahanjou
2008-09-05 19:45 ` Andi Kleen [this message]
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=20080905194501.GZ18288@one.firstfloor.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox