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=-1.0 required=3.0 tests=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 1E621C33C9E for ; Tue, 7 Jan 2020 10:04:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D4C4B20848 for ; Tue, 7 Jan 2020 10:04:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D4C4B20848 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6D2948E0021; Tue, 7 Jan 2020 05:04:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 682A18E001E; Tue, 7 Jan 2020 05:04:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 598EF8E0021; Tue, 7 Jan 2020 05:04:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0236.hostedemail.com [216.40.44.236]) by kanga.kvack.org (Postfix) with ESMTP id 43E468E001E for ; Tue, 7 Jan 2020 05:04:56 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id DF78B180AD804 for ; Tue, 7 Jan 2020 10:04:55 +0000 (UTC) X-FDA: 76350404550.17.oven21_481d70af1f222 X-HE-Tag: oven21_481d70af1f222 X-Filterd-Recvd-Size: 3791 Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Tue, 7 Jan 2020 10:04:55 +0000 (UTC) Received: by mail-oi1-f195.google.com with SMTP id 18so16670071oin.9 for ; Tue, 07 Jan 2020 02:04:55 -0800 (PST) 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=P9OKbMZWRAmiTF6ODcRzRiBwtRnKeMsOcJnKTjB3BHc=; b=uCUNwqZe1k7wPh8Bee0hVVfRX/Iuv9wiJYDtKQRJKlpwxC4oogXDhcOmz5WWi8Qxvy UM66uKpmuoE4dLWB1wIiuf1DHP99WyruUMda8o8389gbA4bKxbU0qeHAlk/RhDfqLGso VtAGv89swJTes+i7IpC8U24VhrKkyEpp3NxTtd4S07OOTXrakjFrcYoDTudxQmdG2ZiT xrunpAqLuAi9aqHCI2tzpkeGbCSi+Goyjbis+D6pk3S98wsyruoq/IDhIIuU85AyIIMm 7TpqwJeXI0iscDrM5MjSJapmE6Nd+tdHlwe9ReK1/EaIkxvp8jcSGY90bxKX1mjyR2Tz dJKw== X-Gm-Message-State: APjAAAX76cZ11kMLqafQ8elsqFnhlbFSajBMkRoZL85ATf3z2OvntUXM F0lJdib2CaVEYtxPG1CoGSeeVIDm82pdRFfJj2g= X-Google-Smtp-Source: APXvYqyuID/tIK9mIb+yQZBB/bC/oQPe9u8oemmaCUDNeX4YehBT5sImEFsyMYn/0lipjpsQ9G820oWS1rko3emytaA= X-Received: by 2002:aca:cd92:: with SMTP id d140mr6575824oig.68.1578391494788; Tue, 07 Jan 2020 02:04:54 -0800 (PST) MIME-Version: 1.0 References: <20191226220205.128664-1-semenzato@google.com> <20191226220205.128664-2-semenzato@google.com> <20200106125352.GB9198@dhcp22.suse.cz> In-Reply-To: <20200106125352.GB9198@dhcp22.suse.cz> From: "Rafael J. Wysocki" Date: Tue, 7 Jan 2020 11:04:43 +0100 Message-ID: Subject: Re: [PATCH 1/2] Documentation: clarify limitations of hibernation To: Michal Hocko Cc: Luigi Semenzato , Linux Memory Management List , Linux Kernel Mailing List , "Rafael J. Wysocki" , Andrew Morton , Geoff Pike 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 Mon, Jan 6, 2020 at 1:53 PM Michal Hocko wrote: > > On Thu 26-12-19 14:02:04, Luigi Semenzato wrote: > [...] > > +Limitations of Hibernation > > +========================== > > + > > +When entering hibernation, the kernel tries to allocate a chunk of memory large > > +enough to contain a copy of all pages in use, to use it for the system > > +snapshot. If the allocation fails, the system cannot hibernate and the > > +operation fails with ENOMEM. This will happen, for instance, when the total > > +amount of anonymous pages (process data) exceeds 1/2 of total RAM. > > + > > +One possible workaround (besides terminating enough processes) is to force > > +excess anonymous pages out to swap before hibernating. This can be achieved > > +with memcgroups, by lowering memory usage limits with ``echo > > > +/dev/cgroup/memory//memory.mem.usage_in_bytes``. However, the latter > > +operation is not guaranteed to succeed. > > I am not familiar with the hibernation process much. But what prevents > those allocations to reclaim memory and push out the anonymous memory to > the swap on demand during the hibernation's allocations? Nothing in particular AFAICS, at least in theory. The approach taken by the hibernation code is rather straightforward: allocate enough memory to store a copy of every page (in RAM) that needs to be saved. These allocations are made one page at a time, so in theory they should not fail as long as there is enough swap space in the system, but I'm probably missing something here.