Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp206440ybg; Tue, 22 Oct 2019 18:58:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqzmLg4oN14wINuI/zLO16z9FzA4BsKgGjJvDVVaGfrwZrxn9ivD9E1H6SjfsPlwSrIsGzCq X-Received: by 2002:a17:906:4d95:: with SMTP id s21mr30420882eju.175.1571795930135; Tue, 22 Oct 2019 18:58:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571795930; cv=none; d=google.com; s=arc-20160816; b=JnVkt3mS4/sH1dt6CvaJ/xSDYSikogzF9qtE6/VguA6IBtfZ5f/Mjo4OOxBd2UU0ZC VTnUmBYuNwIVntNh0fQYAUcNxxdyKdbBssg3pljthCMZwVIpIoMHS7ADpIk9ZQsLksCy 8JROVMEIVoRAu4S4x4lWW2Sv16uqk+UAPpTTtSjKCN08To7lWMgk/dwqTfi8bB+gpeI4 YA3pftQS8Sb4SSYa/r0ytsqv3EkTENUmYbI5BtYrV25FGJqIOl2qbCfaG/16IvKsEgVc 3Vp8IPhYfSPqMmGd+ml/rAMk7kXI9zuvjjr4cna1eVbGf46FevE9GAoUgl+51lLLkNbc wF3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=0Z38w4WeorVLa55pv2bFPQYaKP+W4SvCLyYXgYMK+IY=; b=P8HXpMtBKufOdXCfdvMf2DohOfQzeNnfsxetrqfmSfrOihAtJIPLX2eXTY49Q2mxAC F8jAq93dbkth7nXCSc2gllY0g8AAJ4bHCpnZHeBqRIjaEzE6ZBgvMcxJKb3WQUetZfQW xtJDwo7mgmRYmex6Au4WVLmON4WD42lVIhUq8hpsRGgYG7Eb6tl66pDW2qKVSyxDbSQ0 lS1l16mxBtCfwnU4MhmyQo2lb26tN0YGrSiFL5gV+hjowR56sZUPllQMzwscHBb9/64o M8nffWDmtYHxLFRWAKnflUuLRKObW82zCpkZaEwDXdRuIZlYb1JxMAUIJ1w6nOTUjno9 EFkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Wn7w5KAy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x26si5254120edd.287.2019.10.22.18.58.12; Tue, 22 Oct 2019 18:58:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Wn7w5KAy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733035AbfJVV05 (ORCPT + 99 others); Tue, 22 Oct 2019 17:26:57 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:36865 "EHLO mail-wm1-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726847AbfJVV04 (ORCPT ); Tue, 22 Oct 2019 17:26:56 -0400 Received: by mail-wm1-f48.google.com with SMTP id f22so17544624wmc.2 for ; Tue, 22 Oct 2019 14:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0Z38w4WeorVLa55pv2bFPQYaKP+W4SvCLyYXgYMK+IY=; b=Wn7w5KAyx1ojYoHVRBGGgyNncGa/iKhuHd5rjXLNsG8vDzbKO38J2Qvk71WBeHPv7M b1AxxZPMkvOCIMng/n547Xwq6V4p5a+E8UE17l2+Uk44iM9Y3aOTEVeGU6BqHthEcem/ MhNPnsw8Gs1QfungV7+kD02pWsv2pedejSkFk3FEjsiKE4NsfiaIYLLJy/ZMeoACeohq RVWU3fa59Oz8TSew7u9gsW3+jFsHG7r+5nrgOTXZ7EzEpYxAoa/HkVMn3OZjzfJpXycL EE96D1eSCKwTr8URqmefMtyqrhMlajgcWBcIG3e8T/RIoI+z47wC7d9mXfy5ylJefmRv 8GDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0Z38w4WeorVLa55pv2bFPQYaKP+W4SvCLyYXgYMK+IY=; b=haIiaMAkEaZ8hJWx1+mAS351RALdurhT8Arm0JUfwel0dBb+KA/lYEKKGKBCGOdWYE vuiT3CUChAhfxdGhnijBhXW0vrlH1KCXlRbL6HYtl8EGdP2/KkeECzqeYBAqpV9Zr/s1 qUB0SzeAlQIWFXRe+VJ8l28PgM06c9kV7Dlhh1OomvmFMKP7wlnTgMssMgXnqj+CHZQ3 pOF7Sjx4STacUpkKYUKF+Z2qWqXGza5aBG6Er4t4BAaec6zqg+qgboexe63vwbhBhrgY ze2aJ227sGa1TTa00Adxcu2BkLz/dPinasW9fP1lAobEDxulRNt76c6PZ3ZBaxe4mikO Fehw== X-Gm-Message-State: APjAAAUUzOqd2RDCGTEX95KRUBIubKUU9117v18HlL0lvO3XhSvwnwyG Rz/K4h620X5PnV5M5dOM20Lj2RVx8hXek4zNCcyuBSjwDdI= X-Received: by 2002:a1c:2986:: with SMTP id p128mr2971786wmp.173.1571779613021; Tue, 22 Oct 2019 14:26:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Luigi Semenzato Date: Tue, 22 Oct 2019 14:26:41 -0700 Message-ID: Subject: Re: is hibernation usable? To: "Rafael J. Wysocki" Cc: linux-kernel , Linux PM , Andrew Morton , Geoff Pike , Bas Nowaira , Sonny Rao , Brian Geffon Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thank you for the quick reply! On Tue, Oct 22, 2019 at 1:57 PM Rafael J. Wysocki wrote: > > On Tue, Oct 22, 2019 at 10:09 PM Luigi Semenzato wrote: > > > > Following a thread in linux-pm > > (https://marc.info/?l=linux-mm&m=157012300901871) I have some issues > > that may be of general interest. > > > > 1. To the best of my knowledge, Linux hibernation is guaranteed to > > fail if more than 1/2 of total RAM is in use (for instance, by > > anonymous pages). My knowledge is based on evidence, experiments, > > code inspection, the thread above, and a comment in > > Documentation/swsusp.txt, copied here: > > So I use it on a regular basis (i.e. every day) on a system that often > has over 50% or RAM in use and it all works. > > I also know about other people using it on a regular basis. > > For all of these users, it is usable. > > > "Instead, we load the image into unused memory and then atomically > > copy it back to it original location. This implies, of course, a > > maximum image size of half the amount of memory." > > That isn't right any more. An image that is loaded during resume can, > in fact, be larger than 50% of RAM. An image that is created during > hibernation, however, cannot. Sorry, I don't understand this. Are you saying that, for instance, you can resume a 30 GB image on a 32 GB device, but that image could only have been created on a 64 GB device? > > 2. There's no simple/general workaround. Rafael suggested on the > > thread "Whatever doesn't fit into 50% of RAM needs to be swapped out > > before hibernation". This is a good suggestion: I am actually close > > to achieving this using memcgroups, but it's a fair amount of work, > > and a fairly special case. Not everybody uses memcgroups, and I don't > > know of other reliable ways of forcing swap from user level. > > I don't need to do anything like that. Again, I don't understand. Why did you make that suggestion then? > hibernate_preallocate_memory() manages to free a sufficient amount of > memory on my system every time. Unfortunately this doesn't work for me. I may have described a simple experiment: on a 4GB device, create two large processes like this: dd if=/dev/zero bs=1100M count=1 | sleep infinity & dd if=/dev/zero bs=1100M count=1 | sleep infinity & so that more than 50% of TotalMem is used for anonymous pages. Then echo disk > /sys/power/state fails with ENOMEM. Is this supposed to work? Maybe I am doing something wrong? Hibernation works before I create the dd processes. After I force some of those pages to a separate swap device, hibernation works too, so those pages aren't mlocked or anything. > > 3. A feature that works only when 1/2 of total RAM can be allocated > > is, in my opinion, not usable, except possibly under special > > circumstances, such as mine. Most of the available articles and > > documentation do not mention this important fact (but for the excerpt > > I mentioned, which is not in a prominent position). > > It can be used with over 1/2 of RAM allocated and that is quite easy > to demonstrate. > > Honestly, I'm not sure what your problem is really. I apologize if I am doing something stupid and I should know better before I waste other people's time. I have been trying to explain these issues as best as I can. I have a reproducible failure. I'll be happy to provide any additional detail. > > > Two questions then: > > > > A. Should the documentation be changed to reflect this fact more > > clearly? I feel that the current situation is a disservice to the > > user community. > > Propose changes. Sure, after we resolve the above questions. > > B. Would it be worthwhile to improve the hibernation code to remove > > this limitation? Is this of interest to anybody (other than me)? > > Again, propose specific changes.