On 03/23/2012 06:05 AM, Hugh Dickins wrote:
On Thu, 22 Mar 2012, Jason Mattax wrote:
On 03/22/2012 01:46 PM, Andrew Morton wrote:
On Thu, 22 Mar 2012 10:24:22 -0600
Jason Mattax<jmattax@xxxxxxxxxxxxxxx> wrote:
Swapon very slow with swapfiles.
After upgrading the kernel my swap file loads very slowly, while a swap
partition is unaffected. With the newer kernel (2.6.33.1) I get
# time swapon -v /var/swapfile
swapon on /var/swapfile
swapon: /var/swapfile: found swap signature: version 1, page-size 4,
same byte order
swapon: /var/swapfile: pagesize=4096, swapsize=6442450944,
devsize=6442450944
real 4m35.355s
user 0m0.001s
sys 0m1.786s
while with the older kernel (2.6.32.27) I get
# time swapon -v /var/swapfile
swapon on /var/swapfile
swapon: /var/swapfile: found swap signature: version 1, page-size 4,
same byte order
swapon: /var/swapfile: pagesize=4096, swapsize=6442450944,
devsize=6442450944
real 0m1.158s
user 0m0.000s
sys 0m0.876s
this stays true even for new swapfiles I create with dd.
the file is on an OCZ Vertex2 SSD.
Probably the vertex2 discard problem.
We just merged a patch which will hopefully fix it:
--- a/mm/swapfile.c~swap-dont-do-discard-if-no-discard-option-added
+++ a/mm/swapfile.c
@@ -2103,7 +2103,7 @@ SYSCALL_DEFINE2(swapon, const char __use
p->flags |= SWP_SOLIDSTATE;
p->cluster_next = 1 + (random32() % p->highest_bit);
}
- if (discard_swap(p) == 0&& (swap_flags& SWAP_FLAG_DISCARD))
+ if ((swap_flags& SWAP_FLAG_DISCARD)&& discard_swap(p) == 0)
p->flags |= SWP_DISCARDABLE;
}
But Hugh doesn't like it and won't tell us why :)
Patch worked like a charm for me, thanks.
Thanks for your reports: as Andrew points out, this issue has just
now surfaced; though there was one report of it fourteen months ago.
I'm not surprised that you saw no problem on 2.6.32.27, but I am
very surprised that you see the problem on 2.6.33.1 - I'm wondering
if that's a typo for something else, or a distro kernel which actually
contains changes from later releases?
I can't say why I saw it then, but I got the 2.6.33.1 kernel off of
http://www.kernel.org/pub/linux/kernel/v2.6/ so that I wouldn't have to
worry about distribution changes when reporting the bug here. I just
recompiled the source and verified that it is still affected even with
the newest firmware.
I would expect the slowdown to occur sometime around 2.6.35 (perhaps
one before or after), when use of barriers in the block layer was
deprecated in favour of waiting on completion. That made discard
significantly slower - but unavoidably so. It appears now that the use
of barriers before was incorrect, or potentially incorrect: and if you
had started real swapping within 4m35s of swapon on 2.6.32.7, then you
might have been open to data corruption and mysterious segfaults.
Might: it would have depended upon unspecified behaviour in the drive.
Hugh
--
Jason Mattax
575-418-1791
jmattax@xxxxxxxxxxxxxxx
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>