linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

      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).