From: Rob Landley <rob@landley.net>
To: Martin Steigerwald <ms@teamix.de>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: Slow swap-in with SSD
Date: Wed, 12 Jun 2013 15:42:15 -0500 [thread overview]
Message-ID: <1371069735.2776.100@driftwood> (raw)
In-Reply-To: <201306111634.36327.ms@teamix.de> (from ms@teamix.de on Tue Jun 11 09:34:36 2013)
On 06/11/2013 09:34:36 AM, Martin Steigerwald wrote:
> Hi!
>
> Using Linux 3.10-rc5 on an ThinkPad T520 with Intel Sandybridge
> i5-2620M,
> 8 GiB RAM and Intel SSD 320. Currently I have Zcache enabled to test
> the
> effects of it but I observed similar figures on kernels without
> Zcache.
>
> If I let the kernel swap out for example with
>
> stress -m 1 --vm-keep --vm-bytes 5G
>
> or so, then swapping out is pretty fast, I have seen values around
> 100-200 MiB/s
>
> But on issuing a swapoff command to swap stuff in again, the swap in
> is
> abysmally slow, just a few MiB/s (see below).
>
> I wonder why is that so? The SSD is basically idling around on
> swap-in.
Transaction granularity. Swapping out can queue up large batches of
pages because you can queue up more outgoing pages while the others are
still writing. Swapping _in_ you don't know what you need next until
you resume the process, so you fault in 4k, schedule DMA, resume the
process when it completes, fault on the next page, schedule more DMA,
rinse repeat. Programs don't really execute linearly, so you wind up
with round trip latency to and from device each time.
The problem with doing readahead on swapin is that programs jump around
randomly calling a function here and a function there, so you dunno
which other pages it'll need until it requests them. (Speculatively
faulting in pages when the system is starved of memory usually just
makes the memory shortage worse. This code only runs when there's a
shortage of physical pages.)
Having an ssd just exacerbates the problem, because with the device
itself sped up the round trip latency from all the tiny transactions
comes to dominate.
Rob
--
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>
prev parent reply other threads:[~2013-06-12 20:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-11 14:34 Slow swap-in with SSD Martin Steigerwald
2013-06-12 20:42 ` Rob Landley [this message]
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=1371069735.2776.100@driftwood \
--to=rob@landley.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ms@teamix.de \
/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).