From: Shaohua Li <shli@kernel.org>
To: Minchan Kim <minchan@kernel.org>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hughd@google.com,
riel@redhat.com
Subject: Re: [RFC 1/2]swap: add a simple buddy allocator
Date: Fri, 26 Oct 2012 10:29:05 +0800 [thread overview]
Message-ID: <20121026022905.GA1546@kernel.org> (raw)
In-Reply-To: <20121025002037.GA3838@bbox>
On Thu, Oct 25, 2012 at 09:20:37AM +0900, Minchan Kim wrote:
> Hi Shaohua,
>
> Your idea does make sense to me.
> Below just a few nitpick.
Thanks for your time.
> On Mon, Oct 22, 2012 at 10:30:51AM +0800, Shaohua Li wrote:
> > I'm using a fast SSD to do swap. scan_swap_map() sometimes uses up to 20~30%
> > CPU time (when cluster is hard to find), which becomes a bottleneck.
> > scan_swap_map() scans a byte array to search a 256 page cluster, which is very
> > slow.
> >
> > Here I introduced a simple buddy allocator. Since we only care about 256 pages
> > cluster, we can just use a counter to implement the buddy allocator. Every 256
> > pages use one int to store the counter, so searching cluster is very efficient.
> > With this, scap_swap_map() overhead disappears.
> >
> > This might help low end SD card swap too. Because if the cluster is aligned, SD
> > firmware can do flash erase more efficiently.
>
> Indeed.
>
> >
> > The downside is the cluster must be aligned to 256 pages, which will reduce the
> > chance to find a cluster.
>
> It would be not good for roration device. Can't we make it for only discardable
> device?
This is the biggest concern. Andrew raised it too. If most swap space isn't
full, this isn't a problem. Otherwise, might be. But I didn't find a way to
evaluate how big the chance is reduced. I can try if anybody has ideal
workload. If can't evaluate the chance, I'll choose to only enable it for
discardable device.
Other comments make sense, I'll update in next post.
Thanks,
Shaohua
--
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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-10-26 2:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 2:30 [RFC 1/2]swap: add a simple buddy allocator Shaohua Li
2012-10-22 21:10 ` Andrew Morton
2012-10-25 0:20 ` Minchan Kim
2012-10-26 2:29 ` Shaohua Li [this message]
2012-10-25 11:35 ` Ni zhan Chen
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=20121026022905.GA1546@kernel.org \
--to=shli@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=riel@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;
as well as URLs for NNTP newsgroup(s).