linux-kernel - Re: Slow swap-in with SSD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1371069735.2776.100@driftwood>
Date:	Wed, 12 Jun 2013 15:42:15 -0500
From:	Rob Landley <rob@...dley.net>
To:	Martin Steigerwald <ms@...mix.de>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: Slow swap-in with SSD

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/