Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp21784561ybl; Mon, 6 Jan 2020 11:11:25 -0800 (PST) X-Google-Smtp-Source: APXvYqzlvKDK+nXkQNuXnYd9DNS6xQ1KLIg1FeJCNT4qyb1uu3Vp4Cu2sBHPRdEX8qbvOxBJ4dmr X-Received: by 2002:a05:6830:c2:: with SMTP id x2mr106624875oto.8.1578337885745; Mon, 06 Jan 2020 11:11:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578337885; cv=none; d=google.com; s=arc-20160816; b=Yz9mVocDY+5eDS3PGasEbY6LkWk1Yg2QOubaubERzMV1klmna3iKQWXUyISThwP9Ea zyhGZWfnjsYAYbYf5icqYvNqjHyroVUbyEW6wu0EDO5HUMSADdsFvYv14QtPIE0zLWQD us7Rfd+D1aSf3Y/dCu8tOEhoGB16794ZhgpU8sITOgOHnRWcaDufXNohIxADvD1UYAMS H4OPbQHZb7tGqtDABCDyL2NS8Nzb2+zBpJsnQi+eXGuWYXtgLjyzzhP83d5Q2ZVTVywA MEei8AtuIftZNQj2qCRwtDHEA+cc2JWv1TyyFFOxu8k8WhA39xXvMNxrs2XHFp6zRYOD JlgA== 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=5LH1xkVKc5EmMqeCGdpuKvcGOfW0/ozEbE45hEhF4UA=; b=Q8dfh4JK8ByyREsL7R3IhP8s+W1LnMkzlK/XVUcSRonceSoVYiIevg5rsUqkoYpJTW fkPUQpfaU5oADYe4ME/FIJ3FC2RcVk4Qx7X/OyTvA5mobwWFy7UxC+kGwlWb0pbq1qKm vKxJGGxLtScffzEFSYZJIo67wjr6NjZsgs7OKhdJi1mcX7j+d96cmRMwlvCpzFBQdNyG DW3nCfV1T9FPNVjQjr+aFx3CQgZELtZcKuCkvCpyIRQlW/f7Q3GIG501GPDBiPOQOUiq 2ozKH3zPXcjIdccO5gD790MpjB/kZZMDqnWWoovOaIxnp8t/yAHrciSzKXdypkLsiUD7 evQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=YGpWi9up; 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 g26si37114961otk.324.2020.01.06.11.11.13; Mon, 06 Jan 2020 11:11:25 -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=YGpWi9up; 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 S1726858AbgAFTJJ (ORCPT + 99 others); Mon, 6 Jan 2020 14:09:09 -0500 Received: from mail-io1-f66.google.com ([209.85.166.66]:40184 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726569AbgAFTJJ (ORCPT ); Mon, 6 Jan 2020 14:09:09 -0500 Received: by mail-io1-f66.google.com with SMTP id x1so49725702iop.7 for ; Mon, 06 Jan 2020 11:09:09 -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=5LH1xkVKc5EmMqeCGdpuKvcGOfW0/ozEbE45hEhF4UA=; b=YGpWi9upKyMIuvYn59/QrEvmLOsGoRa1tYwvj3DPI5FDHXO0/xaYjHOeYlvIjm31DK xlcugAawJk+kBE/WTcATHWiXwm5T6LPDwEZ04bKvrPJRsZeD2YRSMi6+v7KWUbZr1JT/ epWy670GKSSckBH4+6m0GiimaibaQ8c5y7u/wcRIgCqtwh8808Mbgj/gdFbU075XLA1U sT4QP4BfL0p26lBTQVIfg2Wl+g0uqeiUuF0pfN+FhBi5siuMfqKrhPFol7llh5mHdAdZ qAAhNhyHws8aEovt1GpT0KRZZ48Rsxcifr0uDfrdWYnSc4w3Ce7la/KJ5CaagEKj5RVI ioMg== 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=5LH1xkVKc5EmMqeCGdpuKvcGOfW0/ozEbE45hEhF4UA=; b=XufwpPrB8HqRGzz2sLXIJO2HVfJyDEh5ilG0z10c5JoQbhsLxCMi7c1DK8cqpwwPMJ QMdI3uc6+ehvulyk5C3ZvvqU2wEoc8FzGs758vMCdCFHgEaeKCKzJr9eOyaGpskz2o9o EMYja3JInPSsUL93uvT9qqpQOTn0GMG65Zb1M8PLn0Qy6yNaLO5XzHRTDiBBz63j09Ve n5NghP9JSC1KEjd7Mqb6ujG7p5JFDcV6g1xmALvRrTZa7eIfseXFRq22yDvalnsF/geq rSej1N5YA/Epp/GQDG6NoMXjl00vlKEmdDS+PpreSHwdf/Fy80d+1GE+N5JLoyHGpoiw 8QUg== X-Gm-Message-State: APjAAAV9BfINFUQtH3e+cF3oSYK6WLDue9l2bPh7QU2B3St2ny7BPCLf GyT+IaYm6/ZczPx5L66JX8CX4ksr7a3Nc9v6ww7tlQ== X-Received: by 2002:a02:910a:: with SMTP id a10mr79638858jag.134.1578337748167; Mon, 06 Jan 2020 11:09:08 -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: Luigi Semenzato Date: Mon, 6 Jan 2020 11:08:56 -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" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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? Note that I removed the cgroup suggestion in later versions of this patch: https://marc.info/?l=linux-pm&m=157800718520897 Also, there was some related discussion here: https://marc.info/?l=linux-kernel&m=157177497015315 Thanks! > -- > Michal Hocko > SUSE Labs