From patchwork Fri Dec 22 10:13:59 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rainer Fiebig X-Patchwork-Id: 10129605 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7498F60318 for ; Fri, 22 Dec 2017 10:14:29 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 649E32A035 for ; Fri, 22 Dec 2017 10:14:29 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 62CD52A044; Fri, 22 Dec 2017 10:14:29 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2F0322A035 for ; Fri, 22 Dec 2017 10:14:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757929AbdLVKO0 (ORCPT ); Fri, 22 Dec 2017 05:14:26 -0500 Received: from mx1.mailbox.org ([80.241.60.212]:41701 "EHLO mx1.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758147AbdLVKOW (ORCPT ); Fri, 22 Dec 2017 05:14:22 -0500 Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 529A646D0D; Fri, 22 Dec 2017 11:14:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-transfer-encoding:content-type:content-type:mime-version :date:date:message-id:subject:subject:from:from:received; s= mail20150812; t=1513937639; bh=UhO/8cLR5Uvvcdl5bhdohzJrMCTDsgjDT b+ZRvV+d8w=; b=XhhDjG5lEjr/IP3XuzSIpRlGuiMdncgFiByJ4fmrMV/E0r28f kH92QAPVv3c964xjBqZpHSC/SN75/WG7ekSZpHkB8s0GKa6y4WkZUeY4rXaI+Loe PFeh0URmZJtO4UwvOrYC3qT66sE+PT2uW1d9pvzotwv+y2qEfzsCXUGAKCSDPu8N iqftrMciy2Wn02sVR9g/aczz/cyhdL9TiiIb+nvDPBoEvp+FhM7GbK+TfQZagQq5 ehH2SNdTyubfDxqAfOij0fjmqOM0iOdyV5dP5oP8HmPAr6ZLNYfDBJ/vB6ACNDyJ pU4sC9EXUfVMjCbdt/T/PptFZcRBpupygzKEw== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de [80.241.56.117]) (amavisd-new, port 10030) with ESMTP id EeEmnBUc8Vxq; Fri, 22 Dec 2017 11:13:59 +0100 (CET) To: linux-pm@vger.kernel.org Cc: Thorsten Leemhuis From: Rainer Fiebig Subject: [patch]: do not subtract NR_FILE_MAPPED in minimum_image_size() Message-ID: <8acc18d9-ba18-21f6-ea33-d47a6596586c@mailbox.org> Date: Fri, 22 Dec 2017 11:13:59 +0100 MIME-Version: 1.0 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi! 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 which is imo wrong. 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. As I don't have 32bit-equipment, I could not test it in such environment, though. The problem has also been discussed in a bug-thread which I closed myself because it obviously led to nowhere (https://bugzilla.kernel.org/show_bug.cgi?id=97201). Thoughts? Rainer Fiebig --- /kernel/power/snapshot.c +++ /kernel/power/snapshot.c @@ -1641,8 +1641,7 @@ * [number of saveable pages] - [number of pages that can be freed in theory] * * where the second term is the sum of (1) reclaimable slab pages, (2) active - * and (3) inactive anonymous pages, (4) active and (5) inactive file pages, - * minus mapped file pages. + * and (3) inactive anonymous pages, (4) active and (5) inactive file