lkml.org 
[lkml]   [2010]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject2.6.35 Regression: Ages spent discarding blocks that weren't used!
Hi all.

I've just given hibernation a go under 2.6.35, and at first I thought
there was some sort of hang in freezing processes. The computer sat
there for aaaaaages, apparently doing nothing. Switched from TuxOnIce to
swsusp to see if it was specific to my code but no - the problem was
there too. I used the nifty new kdb support to get a backtrace, which was:

get_swap_page_of_type
discard_swap_cluster
blk_dev_issue_discard
wait_for_completion

Adding a printk in discard swap cluster gives the following:

[ 46.758330] Discarding 256 pages from bdev 800003 beginning at page
640377.
[ 47.003363] Discarding 256 pages from bdev 800003 beginning at page
640633.
[ 47.246514] Discarding 256 pages from bdev 800003 beginning at page
640889.

...

[ 221.877465] Discarding 256 pages from bdev 800003 beginning at page
826745.
[ 222.121284] Discarding 256 pages from bdev 800003 beginning at page
827001.
[ 222.365908] Discarding 256 pages from bdev 800003 beginning at page
827257.
[ 222.610311] Discarding 256 pages from bdev 800003 beginning at page
827513.

So allocating 4GB of swap on my SSD now takes 176 seconds instead of
virtually no time at all. (This code is completely unchanged from 2.6.34).

I have a couple of questions:

1) As far as I can see, there haven't been any changes in mm/swapfile.c
that would cause this slowdown, so something in the block layer has
(from my point of view) regressed. Is this a known issue?

2) Why are we calling discard_swap_cluster anyway? The swap was unused
and we're allocating it. I could understand calling it when freeing
swap, but when allocating?

Regards,

Nigel


\
 
 \ /
  Last update: 2010-08-04 03:43    [W:0.096 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site