Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2227132ybl; Thu, 30 Jan 2020 13:37:41 -0800 (PST) X-Google-Smtp-Source: APXvYqxnGUM+R2wiTrOjhUP1eUBqqKe3VSdiMDdkxV+VsG+QeH2MKIgWu3i1euITk0l+cJp1C2f4 X-Received: by 2002:a05:6808:4c2:: with SMTP id a2mr4099688oie.118.1580420261113; Thu, 30 Jan 2020 13:37:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580420261; cv=none; d=google.com; s=arc-20160816; b=Op/uVRgmGrO48sxVb1+exC5UbRQ1O2EH3Ub1tbL7T7ZzVpOwI4v5LKevaw5yLrDt0m e31NtxO89J36OvzUM7hBk38GJj6kmcs7McEAqndRaxRMuo+53gZMJHFF7PJgqMJNoBPR yApuNKqc5ULfYmvLq0QrJA8Cl+YOv9w1kfeWKf0UjW9UFVcunt8jThMTSA0vTXa5ZI9P qgBhaP4IvP+NSisO/KeBcx4oTXM0P3jsA1QRRM9ZVf1buCIcSvnerGB5eANMQGPLZYoj 4PqGaT3m7Bd6hJbzVCTA1S3B80m2KElK693j4mxB8Epy6NHIGXSbpkyMrwez4euU6n0+ 4siQ== 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=kmgy5YTSkXUKRp9/UQMqxu8UXHwptRgFx1MTR1gZUIM=; b=1DWy3SHeJCQ/w/eWTy7q9K2EoPTaOJ3ZI4/wnTfLbz7SZieBhq+5tMrJ8D0hBfcqDH 5bXIl78XCKNaNiA2DF1H6YuB4YaaBWheqaRYx2ApFQZnhAy1Xirt/8R8dLZbi8OpvGWr /ZOcXJ3PbSVAlYfMIK15JaeKIbNy1xFwOFBFgxDlR/LCF4aGKXV4vSIbbhe0Lh4v3YQX dqY9tyok77qRHbhkr37XLGT3O44BJEkB8hyUcqlgboDq8GVF+3XxmfyyP3/Y1evsvKU1 aDqg478gew2vab1fP8CVXp48hqGBFedfEsS4miB9X/ZFIMOsikE7g+pwa96H3yHkxNIO XyVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=H0LSjrQU; 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 i194si180389oib.73.2020.01.30.13.37.28; Thu, 30 Jan 2020 13:37:41 -0800 (PST) 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=H0LSjrQU; 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 S1727487AbgA3Vg2 (ORCPT + 99 others); Thu, 30 Jan 2020 16:36:28 -0500 Received: from mail-il1-f193.google.com ([209.85.166.193]:42910 "EHLO mail-il1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727161AbgA3Vg2 (ORCPT ); Thu, 30 Jan 2020 16:36:28 -0500 Received: by mail-il1-f193.google.com with SMTP id x2so4365228ila.9 for ; Thu, 30 Jan 2020 13:36:27 -0800 (PST) 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=kmgy5YTSkXUKRp9/UQMqxu8UXHwptRgFx1MTR1gZUIM=; b=H0LSjrQU/4CzttjbWryHXy45XnpaVRoca6QGkYwwS64Ww91BP+5cIftV5PIATABtiJ 25w1rzjalnFZgC242KYn+YVVHiwLIk4ycXfivd63b8+m+6tBGzj2Y1FDNepPeJEEVKZZ VBnp+gr9Fk0AQr75uC0hGa+fic10OQsJ+raS+5ZeH/RfHJYbbhTIPGshk11F43/Gq1xU SuzolbF0/1FY8rvMaKM4apstLBLStfHWk4MkC9eQRsNku68N1LezXh2ymjhD9YVzqGWj JFmtsUpF9oJciDSpiazzrXacDIgzwWdPe0+VBk3BSF3unEhnh/jFHUs8VfnZwPRzcOGI AByg== 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=kmgy5YTSkXUKRp9/UQMqxu8UXHwptRgFx1MTR1gZUIM=; b=rrCcxa0SDjOOe53ZKvaDFNqxFFD9ZwwueMkoHHqhihe/1yYfhyZ0yA1efxF8OfJGtS q5OQj2ETN6+wQM3eS/cVJIeTWy2i4ZIZJB1MqSERBImqcyTJQHCW23YbYn5a9gbMdxbj qkqeii3qz3aYNVrcg+c2HBZqcSielYeUuhO8LW0U/LQCbk/rBGSFO47Ak4V3x3EC3X0b JBXYghR8sQLkoX1UltPvxiKH6C625vsHT5I6Qq6ttZ5ce9GZ/wKeDTvy+WWg3saeoaO+ ntkpd03lAhlzQKO52cGsCoOcHmYTfY/cQxZrWPBa8Z9uWOBFPONnREXYaUjsU2seRTgM nXNA== X-Gm-Message-State: APjAAAUWkLGJGh52lFmiu0q2uYnIP07HDZyoPyjugC6yNZDYngRsR9VG Kv5lTgRdWyeErsouEZ3yd2AlFfGm2GybO9OARo3wUw== X-Received: by 2002:a92:d642:: with SMTP id x2mr6410444ilp.169.1580420186925; Thu, 30 Jan 2020 13:36:26 -0800 (PST) MIME-Version: 1.0 References: <20191226220205.128664-1-semenzato@google.com> <20191226220205.128664-2-semenzato@google.com> <20200106125352.GB9198@dhcp22.suse.cz> <20200108114952.GR32178@dhcp22.suse.cz> <20200127141637.GL1183@dhcp22.suse.cz> In-Reply-To: From: Luigi Semenzato Date: Thu, 30 Jan 2020 13:36:15 -0800 Message-ID: Subject: Re: [PATCH 1/2] Documentation: clarify limitations of hibernation To: "Rafael J. Wysocki" Cc: Michal Hocko , Linux Memory Management List , linux-kernel , Andrew Morton , Geoff Pike 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 On Thu, Jan 30, 2020 at 1:29 PM Rafael J. Wysocki wrote: > > On Thu, Jan 30, 2020 at 10:11 PM Luigi Semenzato wrote: > > > > On Thu, Jan 30, 2020 at 12:50 PM Rafael J. Wysocki wrote: > > > > > > On Mon, Jan 27, 2020 at 6:21 PM Luigi Semenzato wrote: > > > > > > > > On Mon, Jan 27, 2020 at 8:28 AM Rafael J. Wysocki wrote: > > > > > > > > > > On Mon, Jan 27, 2020 at 5:13 PM Luigi Semenzato wrote: > > > > > > > > > > > > On Mon, Jan 27, 2020 at 6:16 AM Michal Hocko wrote: > > > > > > > > > > > > > > On Fri 24-01-20 08:37:12, Luigi Semenzato wrote: > > > > > > > [...] > > > > > > > > The purpose of my documentation patch was to make it clearer that > > > > > > > > hibernation may fail in situations in which suspend-to-RAM works; for > > > > > > > > instance, when there is no swap, and anonymous pages are over 50% of > > > > > > > > total RAM. I will send a new version of the patch which hopefully > > > > > > > > makes this clearer. > > > > > > > > > > > > > > I was under impression that s2disk is pretty much impossible without any > > > > > > > swap. > > > > > > > > > > > > I am not sure what you mean by "swap" here. S2disk needs a swap > > > > > > partition for storing the image, but that partition is not used for > > > > > > regular swap. > > > > > > > > > > That's not correct. > > > > > > > > > > The swap partition (or file) used by s2disk needs to be made active > > > > > before it can use it and the mm subsystem is also able to use it for > > > > > regular swap then. > > > > > > > > OK---I had this wrong, thanks. > > > > > > > > > > If there is no swap, but more than 50% of RAM is free > > > > > > or reclaimable, s2disk works fine. If anonymous is more than 50%, > > > > > > hibernation can still work, but swap needs to be set up (in addition > > > > > > to the space for the hibernation image). The setup is not obvious and > > > > > > I don't think that the documentation is clear on this. > > > > > > > > > > Well, the entire contents of RAM must be preserved, this way or > > > > > another, during hibernation. That should be totally obvious to anyone > > > > > using it really. > > > > > > > > Yes, that's obvious. > > > > > > > > > Some of the RAM contents is copies of data already there in the > > > > > filesystems on persistent storage and that does not need to be saved > > > > > again. Everything else must be saved and s2disk (and Linux > > > > > hibernation in general) uses active swap space to save these things. > > > > > This implies that in order to hibernate the system, you generally need > > > > > the amount of swap space equal to the size of RAM minus the size of > > > > > files mapped into memory. > > > > > > > > > > So, to be on the safe side, the total amount of swap space to be used > > > > > for hibernation needs to match the size of RAM (even though > > > > > realistically it may be smaller than that in the majority of cases). > > > > > > > > This all makes sense, but we do this: > > > > > > > > -- add resume=/dev/sdc to the command line > > > > -- attach a disk (/dev/sdc) with size equal to RAM > > > > -- mkswap /dev/sdc > > > > -- swapon /dev/sdc > > > > -- echo disk > /sys/power/state > > > > > > > > and the last operation fails with ENOMEM. Are we doing something > > > > wrong? Are we hitting some other mm bug? > > > > > > I would expect this to work, so the fact that it doesn't work for you > > > indicates a bug somewhere or at least an assumption that doesn't hold. > > > > > > Can you please remind me what you do to trigger the unexpected behavior? > > > > Yes, I create processes that use a large amount of anon memory, more > > than 50% of RAM, like this: > > > > dd if=/dev/zero bs=1G count=1 | sleep infinity > > > > I think dd has a 2 GB limit, or around that number, so you'll need a > > few of those. > > And then you get -ENOMEM from hibernate_preallocate_memory(), or from > somewhere else? That is correct. More precisely, preallocate_image_memory() doesn't get enough pages, and then preallocate_image_highmem() either gets nothing, or in any case too little.