summaryrefslogtreecommitdiff
path: root/kernel/power/main.c
diff options
context:
space:
mode:
authorRainer Fiebig <jrf@mailbox.org>2017-12-22 13:13:59 +0300
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2018-01-05 16:46:25 +0300
commitbdbc98abb3aa323f6323b11db39c740e6f8fc5b1 (patch)
tree59a2b638f06ac896f3993c36953a2ea53cff5dcc /kernel/power/main.c
parent30a7acd573899fd8b8ac39236eff6468b195ac7d (diff)
downloadlinux-bdbc98abb3aa323f6323b11db39c740e6f8fc5b1.tar.xz
PM: hibernate: Do not subtract NR_FILE_MAPPED in minimum_image_size()
s2disk/s2both may fail unnecessarily and erratically if NR_FILE_MAPPED is high - for instance when using VMs with VirtualBox and perhaps VMware Player. In those situations s2disk becomes unreliable and therefore unusable. A typical scenario is: user issues a s2disk and it fails. User issues a second s2disk immediately after that and it succeeds. And user wonders why. The problem is caused by minimum_image_size() in snapshot.c. The value it returns is roughly 100% too high because NR_FILE_MAPPED is subtracted in its calculation. Eventually the number of preallocated image pages is falsely too low. This doesn't matter as long as NR_FILE_MAPPED-values are in a normal range or in 32bit-environments as the code allows for allocation of additional pages from highmem. But with the high values generated by VirtualBox-VMs (a 2-GB-VM causes NR_FILE_MAPPED go up by 2 GB) it may lead to failure in 64bit-systems. Not subtracting NR_FILE_MAPPED in minimum_image_size() solves the problem. I've done at least hundreds of successful s2both/s2disk now on an x86_64 system (with and without VirtualBox) which gives me some confidence that this is right. It has turned s2disk/s2both from unusable into 100% reliable. Link: https://bugzilla.kernel.org/show_bug.cgi?id=97201 Signed-off-by: Rainer Fiebig <jrf@mailbox.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'kernel/power/main.c')
0 files changed, 0 insertions, 0 deletions