From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58EF5C35242 for ; Tue, 11 Feb 2020 19:50:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 016C52086A for ; Tue, 11 Feb 2020 19:50:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=colorremedies-com.20150623.gappssmtp.com header.i=@colorremedies-com.20150623.gappssmtp.com header.b="lYk23Ksw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 016C52086A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=colorremedies.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 48AF46B0314; Tue, 11 Feb 2020 14:50:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 43B336B0315; Tue, 11 Feb 2020 14:50:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3522C6B0316; Tue, 11 Feb 2020 14:50:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) by kanga.kvack.org (Postfix) with ESMTP id 1D1856B0314 for ; Tue, 11 Feb 2020 14:50:44 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id CE8434435 for ; Tue, 11 Feb 2020 19:50:43 +0000 (UTC) X-FDA: 76478888766.11.cloud89_5da12055e122b X-HE-Tag: cloud89_5da12055e122b X-Filterd-Recvd-Size: 4790 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Tue, 11 Feb 2020 19:50:43 +0000 (UTC) Received: by mail-wr1-f54.google.com with SMTP id c9so14038783wrw.8 for ; Tue, 11 Feb 2020 11:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=colorremedies-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=WqxUYqEpPmxSMfoCR85ATAaqQL/0auI4sMXPaDoF3dA=; b=lYk23KswRwUiO/055yzsESy1STybXtU6jUf94Xb7YZPi4/dBX7rpCEcIPgIip0xhyN f1x3nu97YqRZ6S91cQ868/+AAacYXhPhn1ky9IijgGi71WoeG1O703CsTkWyEHGsCkqt pWEuF1WgUavn7Ab+q4c6cSxvtAJsROuC8ogm1tHnW568xJEze9vV5bJCmlwEuqK/xPlH lzXCRNfCrdLBAmVwTj0RDY4HybchPRVumZK/uEKt9ENysD55IIJOrqEIPS9eb7S/WGrP HAPoqTLf9Xgr8fs+sLA/tL+u5N7ZQroljF1vNwHZ84B81kVyG8ex0YkkE5FfzdQMyc00 Yi5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=WqxUYqEpPmxSMfoCR85ATAaqQL/0auI4sMXPaDoF3dA=; b=mTr7Kn0R1pfNKqEGH8QUanE5yTMo4rysRKJbWh8VJYZ2mN56anyUIisW0YCiuazfU6 /8FZTWTolg57TEe76JAma7JlBp9dL0vL1wyQy2BSNG1uWfMGJg2JkySyK7vrm1HdearH OMNfTc85KeOmRf/nGYagpl8OmUxsgU4hIEikJZTJ2qg1+YGPUDf0W/YE0406zIJdtaOa WXFK7qrGRkihLtjylaXi64vrpVx3pP0/BpPLxVFFaEhsPU1TwoLWAn+Iu5qW4NdFoO1P NPqn9z9j0XZhgqB+4nn0qzL5mjkw0OYFQEIv/xuNgcx3oAQaLE3A7ltKUZEj3rMnfvnn Y+hg== X-Gm-Message-State: APjAAAXERfYGGwCZpDlf9iGiw9Wis7nvqoHPB1+qKt3/34GK0Gzh60Oa O/3zrjkfBep/M41tZmpxur61yug1lGw3O6nJL4Ck+fOAM5g= X-Google-Smtp-Source: APXvYqxcM2sTvk0/318RT1acjgz5WNAlPZNj/zaesJ8S9x8ttEiB8O1+aNRjcRihej4mwwZeT2kjAbyJ84VvhAl1kQY= X-Received: by 2002:adf:8564:: with SMTP id 91mr10575198wrh.252.1581450641711; Tue, 11 Feb 2020 11:50:41 -0800 (PST) MIME-Version: 1.0 From: Chris Murphy Date: Tue, 11 Feb 2020 12:50:25 -0700 Message-ID: Subject: re: is hibernation usable? To: linux-mm@kvack.org Cc: semenzato@google.com Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Original thread: https://lore.kernel.org/linux-mm/CAA25o9RSWPX8L3s=r6A+4oSdQyvGfWZ1bhKfGvSo5nN-X58HQA@mail.gmail.com/ This whole thread is a revelation. I have no doubt most users have no idea that hibernation image creation is expected to fail if more than 50% RAM is used. Please bear with me while I ask some possibly rudimentary questions to ensure I understand this in simple terms. Example system: 32G RAM, all of it used, plus 2G of page outs (into the swap device). + 2G already paged out to swap + 16GB needs to be paged out to swap, to free up enough memory to create the hibernation image + 8-16GB for the (compressed) hibernation image to be written to a *contiguous* range within swap device This suggests a 26G-34G swap device, correct? (I realize that this swap device could, in another example, contain more than 2G of page outs already, and that would only increase this requirement.) Is there now (or planned) an automatic kernel facility that will do the eviction automatically, to free up enough memory, so that the hibernation image can always be successfully created in-memory? If not, does this suggest some facility needs to be created, maybe in systemd, coordinating with the desktop environment? I don't need to understand the details but I do want to understand if this exists, will exist, and where it will exist. One idea floated on Fedora devel@ a few months ago by a systemd developer, is to activate a swap device at hibernation time. That way the system is constrained to a smaller swap device, e.g. swap on /dev/zram during normal use, but can still hibernate by activating a suitably sized swap device on-demand. Do you anticipate any problems with this idea? Could it be subject to race conditions? Is there any difference in hibernation reliability between swap partitions, versus swapfiles? I note there isn't a standard interface for all file systems, notably Btrfs has a unique requirement [1] Are there any prospects for signed hibernation images, in order to support hibernation when UEFI Secure Boot is enabled? What about the signing of swap? If there's a trust concern with the hibernation image, and I agree that there is in the context of UEFI SB, then it seems there's likewise a concern about active pages in swap. Yes? No? [1] https://lore.kernel.org/linux-btrfs/CAJCQCtSLYY-AY8b1WZ1D4neTrwMsm_A61-G-8e6-H3Dmfue_vQ@mail.gmail.com/ Thanks! -- Chris Murphy