From: Martin Steigerwald <ms@teamix.de>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Slow swap-in with SSD
Date: Tue, 11 Jun 2013 16:34:36 +0200 [thread overview]
Message-ID: <201306111634.36327.ms@teamix.de> (raw)
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.
merkaba:~> stress -m 1 --vm-keep --vm-bytes 5G
stress: info: [10998] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
^C
merkaba:~> swapon -s
Filename Type Size Used Priority
/dev/mapper/merkaba-swap partition 12582908 2168872 -1
merkaba:~> free -m
total used free shared buffers cached
Mem: 7767 2342 5425 0 0 305
-/+ buffers/cache: 2036 5730
Swap: 12287 2182 10105
merkaba:~> vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 2234528 5554868 40 313056 5 14 532 53 225 309 6 2 91 0
0 0 2234508 5554736 40 313168 60 0 60 0 573 926 0 1 99 0
0 0 2234508 5554736 40 313168 0 0 0 0 708 1317 1 1 98 0
0 0 2234492 5554612 40 313168 52 0 52 0 530 946 0 1 99 0
1 0 2193204 5524412 372 340940 1908 0 2476 0 3857 6961 1 22 75 2
1 0 2190412 5522924 372 341044 0 0 0 0 2334 4606 0 26 74 0
1 0 2187116 5521188 372 341044 0 0 0 0 2212 4625 0 26 74 0
1 0 2182972 5517964 372 341072 1852 0 1852 0 3635 6901 0 25 73 2
1 0 2178332 5515112 372 341076 196 0 196 0 2460 4997 1 26 73 1
2 0 2172832 5511980 372 341076 104 0 104 0 2275 4742 0 26 74 0
1 0 2165116 5508136 372 341076 12 0 12 0 2320 4741 0 26 74 0
1 0 2154596 5501936 372 341080 92 0 92 0 2263 4768 0 26 74 0
1 0 2144784 5494620 372 341108 3048 0 3048 0 4491 8359 1 24 73 3
1 0 2135528 5486748 372 341092 5376 0 5376 0 5969 10706 1 23 72 4
1 0 2131528 5481984 372 341268 2160 0 4776 0 3841 7337 1 24 72 3
1 3 2128708 5478008 372 341544 3324 0 3648 0 3844 7318 0 24 72 4
2 0 2126884 5463440 372 353084 2956 0 95900 0 9990 19942 1 27 51 21
1 0 2124888 5461332 372 353084 1592 0 1592 0 3453 6590 0 25 73 2
2 1 2118644 5439740 372 360832 6364 0 86884 4 10292 20131 1 29 42 27
1 0 2113572 5415604 372 370908 4812 0 33340 0 9810 18000 5 33 52 10
1 0 2111736 5413872 372 370684 1596 0 1684 0 3475 6487 1 25 73 2
1 0 2109836 5411888 372 370728 1912 0 1912 0 3571 6776 0 25 73 2
1 0 2107804 5410028 372 370740 1360 0 1360 0 3162 6164 0 25 73 2
1 0 2106104 5407996 372 370740 1820 0 1820 0 3355 6493 0 25 73 2
1 0 2103756 5406136 372 370776 976 0 976 0 3057 5974 1 26 71 1
1 0 2101548 5403160 372 370776 2356 0 2356 0 3588 6939 1 26 71 2
1 0 2099000 5400804 372 370776 1948 0 1948 0 3666 6884 1 25 72 3
2 0 2096784 5398820 372 370776 1944 0 1944 0 3881 7383 1 27 70 2
1 0 2094976 5397208 372 370776 1584 0 1584 0 3541 6564 1 25 73 2
1 0 2092924 5394976 372 370776 1752 0 1752 0 3513 6649 0 24 73 2
1 0 2089460 5391752 372 370776 1072 0 1072 0 3051 5932 1 25 73 2
1 0 2084456 5389116 372 370776 496 0 496 0 2694 5272 0 26 74 1
1 1 2081160 5386256 372 370804 2116 0 2116 696 4039 7462 1 25 73 2
3 0 2077804 5383156 372 370816 3004 0 3004 0 4394 8157 1 24 73 3
1 0 2075284 5380800 372 370816 1856 0 1856 0 3570 6831 1 25 73 2
1 0 2073544 5379064 372 370824 1452 0 1452 0 3246 6270 0 25 73 2
According to atop the SSD is about 5-15% busy.
Swapoff is quite CPU busy:
PID TID RUID EUID THR SYSCPU USRCPU VGROW RGROW RDDSK WRDSK ST EXC S CPUNR CPU CMD 1/7
11006 - root root 1 7.54s 0.00s 0K 0K 30100K 0K -- - R 0 76% swapoff
PID TID RUID EUID THR SYSCPU USRCPU VGROW RGROW RDDSK WRDSK ST EXC S CPUNR CPU CMD 1/8
11006 - root root 1 9.65s 0.00s 0K 0K 7148K 0K -- - R 3 97% swapoff
PID TID RUID EUID THR SYSCPU USRCPU VGROW RGROW RDDSK WRDSK ST EXC S CPUNR CPU CMD 1/6
11006 - root root 1 9.60s 0.00s 0K 0K 8752K 0K -- - R 3 96% swapoff
Anyway idea?
I can try this without Zcache as well. But I am pretty sure it was slow
as well. But I had ZCACHE compiled in, as far as I guess from hints on
the web, I bet its basically a no-op unless enabled with "zcache" kernel
commandline parameter.
Thanks,
--
Martin Steigerwald - teamix GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90
--
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 reply other threads:[~2013-06-11 14:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-11 14:34 Martin Steigerwald [this message]
2013-06-12 20:42 ` Slow swap-in with SSD Rob Landley
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=201306111634.36327.ms@teamix.de \
--to=ms@teamix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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).