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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 501DDC35242 for ; Tue, 11 Feb 2020 22:23:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 01C6A206D7 for ; Tue, 11 Feb 2020 22:23:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="TIP+iM/O" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 01C6A206D7 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 96EEA6B0346; Tue, 11 Feb 2020 17:23:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 91F4A6B0347; Tue, 11 Feb 2020 17:23:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 835746B0348; Tue, 11 Feb 2020 17:23:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0187.hostedemail.com [216.40.44.187]) by kanga.kvack.org (Postfix) with ESMTP id 698616B0346 for ; Tue, 11 Feb 2020 17:23:43 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 19C358245578 for ; Tue, 11 Feb 2020 22:23:43 +0000 (UTC) X-FDA: 76479274326.11.grade23_77b740c83c41a X-HE-Tag: grade23_77b740c83c41a X-Filterd-Recvd-Size: 6381 Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Tue, 11 Feb 2020 22:23:42 +0000 (UTC) Received: by mail-io1-f67.google.com with SMTP id m25so13676273ioo.8 for ; Tue, 11 Feb 2020 14:23:42 -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=JU6PMwGHknX2q09yoiBf7M1Wg6vGoSe1eZZnZCt2Ecw=; b=TIP+iM/Ooz2vo/xA8plOagcbnoeIBUX0Or8zvvsZ4NFz9gSVJDbZhF0m5qb6XD7aAq S3pcDgAhliulbUlEIkzcws8V4FUhXypXiwlAEQ1IsMUDt8kAuVUTK4SkUuD4YPaVp9qi 5PNzsYQbkiqDuWbHIJoujVDMVWuwkMaW4fVujrhzN3ukEHq6luIduaAyMWR7Bb5L6Epc oBngSlb91pFkAHQmkTkphYuE59+BqY59zUWsRGNkt1iDabQiK2RLVCG3lQgFaLMms6gZ 9Gxp31VqLJ9iiqjQxGoT088y6mEuulfkNu25Jbq522XnIt+WaLa5VvsOFtcBrSBd0dit xGcA== 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=JU6PMwGHknX2q09yoiBf7M1Wg6vGoSe1eZZnZCt2Ecw=; b=To/89HkNr08ZOKoSPXxSTZjwP0Vj3E5E5vMyobyfSpRTfL/BfmdPv+BBYv1+ha8bPs OU0uXm8XQz3VzHiJl5FDQCHDD2xYNtFVrxVHroCIy87n78ciTdkmACY/YZJqh+nJRVEG EBaZb9EfzTEEAII7vyd1DlNn/7Z90Xl+w+faYzVJarXuWE0y/9PPpODzyu5qB8mejMuW QaUqeOfUIY+O4p/xQft+jvAnFLy84i1gcgSL5L+Y5NPoq2SM8sxOALv+qkJtoTF1/XUY G3Q2SoQcszmjXrQa2bLJaUEzhF/01bKx0WrPyNxW+dRz0r5kMOP/99ea7n3Vxrdvz475 cPaQ== X-Gm-Message-State: APjAAAUFONsB5yXrFkkokmDf4Jfp+CteX4Kfd52rIyuVQ7aTvFusodHb +jzUjqQAAydoLPIDpjSiSzb+FQjAHqj6sLRtgKgE5w== X-Google-Smtp-Source: APXvYqy7/WS2Ohq4BQ/tjseYIsa4Ww9tKPy/Ocw3O4XiUEsTKDCZugtxT0HxTaRP7PxZNBVasoVY9QWIBST6UI9LQ2c= X-Received: by 2002:a5d:9157:: with SMTP id y23mr15214426ioq.199.1581459821466; Tue, 11 Feb 2020 14:23:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Luigi Semenzato Date: Tue, 11 Feb 2020 14:23:30 -0800 Message-ID: Subject: Re: is hibernation usable? To: Chris Murphy Cc: Linux Memory Management List 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: On Tue, Feb 11, 2020 at 11:50 AM Chris Murphy wrote: > > 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. To be clear, I am not completely sure of this. Other developers are not in agreement with this (as you can see from the thread). However, I can easily and consistently reproduce the memory allocation failure when anon is >50% of total. According to others, the image allocation should reclaim pages by forcing anon pages to swap. I don't understand if/how the swap partition accommodates both swapped pages and the hibernation image, but in any case, in my experiments, I allocate a swap disk the same size of RAM, which should be sufficient (again, according to the threads). > 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. I have a workaround, but it needs memcgroups. You can echo $limit > .../$cgroup/memory.mem.limit_in_bytes and if your current usage is greater than $limit, and you have swap, the operation will block until enough pages have been swapped out to satisfy the limit. Even this isn't guaranteed to work, even with enough free swap. The limit adjustment invokes mem_cgroup_resize_limit() which contains a loop with multiple retries of a call to do_try_to_free_pages(). The number of retries looks like a heuristic, and I've seen the resizing fail. > 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