linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>,
	Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [PATCH -mm] make swapin readahead skip over holes
Date: Mon, 09 Jan 2012 22:09:20 -0500	[thread overview]
Message-ID: <4F0BABE0.8080107@redhat.com> (raw)
In-Reply-To: <4F0B7D1F.7040802@gmail.com>

On 01/09/2012 06:49 PM, KOSAKI Motohiro wrote:
> (1/9/12 6:10 PM), Rik van Riel wrote:
>> Ever since abandoning the virtual scan of processes, for scalability
>> reasons, swap space has been a little more fragmented than before.
>> This can lead to the situation where a large memory user is killed,
>> swap space ends up full of "holes" and swapin readahead is totally
>> ineffective.
>>
>> On my home system, after killing a leaky firefox it took over an
>> hour to page just under 2GB of memory back in, slowing the virtual
>> machines down to a crawl.
>>
>> This patch makes swapin readahead simply skip over holes, instead
>> of stopping at them. This allows the system to swap things back in
>> at rates of several MB/second, instead of a few hundred kB/second.
>
> If I understand correctly, this patch have
>
> Pros
> - increase IO throughput

By about a factor 3-10 in my tests here.

> Cons
> - increase a risk to pick up unrelated swap entries by swap readahead

I do not believe there is a very large risk of this, because
since we introduced rmap, we have been placing unrelated
pages right next to each other in swap.

This is also why, since 2.6.28, the kernel places newly swapped
in pages on the INACTIVE_ANON list, where they should not
displace the working set.

Another factor is that swapping on modern systems is often a
temporary thing. During a load spike, things get swapped out
and run slowly. After the load spike is over, or some memory
hog process got killed, we want the system to recover to normal
performance as soon as possible.  This often involves swapping
everything back into memory.

-- 
All rights reversed

  reply	other threads:[~2012-01-10  3:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-09 23:10 [PATCH -mm] make swapin readahead skip over holes Rik van Riel
2012-01-09 23:49 ` KOSAKI Motohiro
2012-01-10  3:09   ` Rik van Riel [this message]
2012-01-11  7:14     ` KOSAKI Motohiro
2012-01-11  8:01       ` KOSAKI Motohiro
2012-01-11  8:05         ` KOSAKI Motohiro
2012-01-11 14:11         ` John Stoffel
2012-01-11 19:17           ` Christoph Lameter
2012-01-11 21:03             ` John Stoffel
2012-01-11 22:25               ` KOSAKI Motohiro
2012-01-11 23:15       ` Andrew Morton
2012-01-11 16:51 ` Mel Gorman
2012-01-11 19:23   ` Rik van Riel
2012-01-12 14:33     ` Mel Gorman

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=4F0BABE0.8080107@redhat.com \
    --to=riel@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kosaki.motohiro@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    /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).