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 5C0B9C3F68F for ; Mon, 6 Jan 2020 19:09:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 053C9208C4 for ; Mon, 6 Jan 2020 19:09:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="YGpWi9up" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 053C9208C4 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 5048B8E0005; Mon, 6 Jan 2020 14:09:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B5088E0001; Mon, 6 Jan 2020 14:09:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CCB98E0005; Mon, 6 Jan 2020 14:09:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0227.hostedemail.com [216.40.44.227]) by kanga.kvack.org (Postfix) with ESMTP id 25BD98E0001 for ; Mon, 6 Jan 2020 14:09:10 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id CA9F68249980 for ; Mon, 6 Jan 2020 19:09:09 +0000 (UTC) X-FDA: 76348147218.26.bite84_6d123060e901a X-HE-Tag: bite84_6d123060e901a X-Filterd-Recvd-Size: 4941 Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Mon, 6 Jan 2020 19:09:09 +0000 (UTC) Received: by mail-io1-f65.google.com with SMTP id d15so6299804iog.3 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=ihg1wQxwNlWsSjDQv334wmO0AyQbC1B+bLtJXOw/oCEZhfZkLe2e/4N3BwI7naKmrv BmYbiCx/b0eopSO4eZWqat60k0zuWyolgZsgRf6akUcBiHXfoJ0zTF3XbU64/X6/406J ZURNaYOURfpzq1S+NvGmxUIvIxmnKL0oeA/aReQTo2AnkMd3HU2s4fIMkW//T/wMHTMo PCr/d1ZU2qnavF+DiHKJjuommqk7kMpo9XWe6gv/g6i07ieRv3HlxWePFZMYTU6W9p7Y AICBwWOKBYprs/616iTEr7GIb1IWkk3TPLBCma5Igm6qnxjmTlYwPVe9M6EY28TOtymW mLNw== X-Gm-Message-State: APjAAAUOdOUEAhD1+rzcOaP2BYNsC9xt6b/hm9UtJHNxqx4nO6an+KDW fISd7dUt4JsF4xQxaPmvKXB8MW59BvJq0uTq6u1ILg== X-Google-Smtp-Source: APXvYqwqP+NtxtTdTXYzk0kr4E4hPHW59SC50OrvliLIAV6AcRYlhCflxv2wBey1Y+3ca6PlDxBYzCqvWnibi2J8Rlw= 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" 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 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