On Thu, 22 Mar 2012, Jason Mattax wrote:

On 03/22/2012 01:46 PM, Andrew Morton wrote:

quoted

On Thu, 22 Mar 2012 10:24:22 -0600
Jason Mattax[off-list ref]  wrote:

quoted

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

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>