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,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 52DBAC35242 for ; Fri, 24 Jan 2020 16:37:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E341D2070A for ; Fri, 24 Jan 2020 16:37:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="PseXiLUE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E341D2070A 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 534CC6B0005; Fri, 24 Jan 2020 11:37:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E4F66B0006; Fri, 24 Jan 2020 11:37:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D4B36B0007; Fri, 24 Jan 2020 11:37:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0111.hostedemail.com [216.40.44.111]) by kanga.kvack.org (Postfix) with ESMTP id 257C36B0005 for ; Fri, 24 Jan 2020 11:37:27 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id BD9FE180AD804 for ; Fri, 24 Jan 2020 16:37:26 +0000 (UTC) X-FDA: 76413083292.27.actor52_7b282d045d20d X-HE-Tag: actor52_7b282d045d20d X-Filterd-Recvd-Size: 6928 Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Fri, 24 Jan 2020 16:37:26 +0000 (UTC) Received: by mail-io1-f66.google.com with SMTP id t26so2568170ioi.13 for ; Fri, 24 Jan 2020 08:37:26 -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=RhdyP2R1pzKJgQYs4b5e0DuELiessERSVhnO5/9H1lM=; b=PseXiLUEGavafEcyD3qENC7uBgBp0mUuS+ESgjyl6Rma5dbjIopC9D1sF57pwNjkD9 pOsXzgzEKsPbiFexf+GUHQTP0p447KvT09vLTJOexKNQ63yCRihECeD0Af2vycVsA3/W wIHdir+Ty9bw5qMVNdGLuOquZmprHgkK6IE00EoKyETVa1//IbWc0sbRWQOlPcdEz9b5 woySlNgbyJAATurbh8tDp3b7wrbtw75FTpDlHcE0bHnDdqMuRgbNbgihxD1qrg5n+6v3 ZfHWnvl474YcqPgWltD2PZ4c9MSIv1Gj21o7dMoGyKvzlwSTA0TR76nXMCYm+oGCP9+m bQXA== 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=RhdyP2R1pzKJgQYs4b5e0DuELiessERSVhnO5/9H1lM=; b=SF4Eo3TkGG72l3TxgtGGZB3HYwHOGdwUKF4zEB2d04wdNYvwffjjxceK3dcpKyMkqB OU7yTRFO8uIXWKbo7gefjgkziO1wROoXjjtzYjF+gqgpQR6tG+MmBaPwt4LPVEshQH6i z32kyWlpa1PTgasPoLcM4KSr4dRz7r2Xv1BrslqLaswrfbRTZ21GJbFjltNtuBEOgodz ZQgE2xuCO1RqdvrsmEQFBcF7UE42bvmFgNU6GCtswA3jV0jz9j6owi0SGj4yJ9wa8srJ Cc0juYjuqF9V2oVMI2I0WFsZ50djh7GM+D6G7xoRhtbP4QGKEGTuzp7Uv0lo8TvUzPDZ 8YYg== X-Gm-Message-State: APjAAAXYrapZUNPy5luRXYB8j+7SCMITOt23CGVI+DUO3dw5tWYXKMLS 4YrzCbi64yHpW82PwSq5r+OpSKIJZKvfQG4ZzDdOxQ== X-Google-Smtp-Source: APXvYqxh3uR7vuRcLiz3bx95DqTAqg+FJcm6nZKBhbhrkKWFae/Iw9Orj/T3WTBf7kj3f+U2uCP2WyM8tAxC1mr2bqM= X-Received: by 2002:a05:6638:3b6:: with SMTP id z22mr3059846jap.35.1579883845056; Fri, 24 Jan 2020 08:37:25 -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> In-Reply-To: <20200108114952.GR32178@dhcp22.suse.cz> From: Luigi Semenzato Date: Fri, 24 Jan 2020 08:37:12 -0800 Message-ID: Subject: Re: [PATCH 1/2] Documentation: clarify limitations of hibernation To: Michal Hocko Cc: Linux Memory Management List , linux-kernel , "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: Thank you all for the replies and sorry for the delay (vacation + flu). This has given me various ideas for experiments and I will try to get to them in the future. For now, the cgroup workaround (described in my first version of the patch, but removed later) will do for us. 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. >From this discussion, it seems that it should be possible to set up swap and hibernation in a way that increases the probability of success when entering hibernation (or maybe make it a certainty?). It would be useful to include such setup in the documentation. I don't know how to do this (yet) but if anybody does, it would be a great contribution. Thanks! On Wed, Jan 8, 2020 at 3:49 AM Michal Hocko wrote: > > On Mon 06-01-20 11:08:56, Luigi Semenzato wrote: > > On Mon, Jan 6, 2020 at 4:53 AM 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? > > > > Good question, thanks. > > > > The hibernation image is stored into a swap device (or partition), so > > I suppose one could set up two swap devices, giving a lower priority > > to the hibernation device, so that it remains unused while the kernel > > reclaims pages for the hibernation image. > > I do not think hibernation can choose which swap device to use. Having > an additional swap device migh help though because there will be more > space to swap out to. > > > If that works, then it may be appropriate to describe this technique > > in Documentation/power/swsusp.rst. There's a brief mention of this > > situation in the Q/A section, but maybe this deserves more visibility. > > > > In my experience, the page allocator is prone to giving up in this > > kind of situation. But my experience is up to 4.X kernels. Is this > > guaranteed to work now? > > OK, I can see it now. I forgot about the ugly hack in the page allocator > that hibernation is using. If there is no way to make a forward progress > for the allocation and we enter the allocator oom path (__alloc_pages_may_oom) > pm_suspended_storage() bails out early and the allocator gives up. > > That being said allocator would swap out processes so it doesn't make > much sense to do that pro-actively. It can still fail if the swap is > depleted though and then the hibernation gives up. This makes some sense > because you wouldn't like to have something killed by the oom killer > while hibernating right? Graceful failure should be a preferable action > and let you decide what to do IMHO. > -- > Michal Hocko > SUSE Labs