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 03193C35642 for ; Fri, 21 Feb 2020 09:04:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C1C5E2071E for ; Fri, 21 Feb 2020 09:04:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C1C5E2071E 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 5E8056B000D; Fri, 21 Feb 2020 04:04:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 572CA6B000E; Fri, 21 Feb 2020 04:04:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 461AE6B0010; Fri, 21 Feb 2020 04:04:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0036.hostedemail.com [216.40.44.36]) by kanga.kvack.org (Postfix) with ESMTP id 289A76B000D for ; Fri, 21 Feb 2020 04:04:31 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id AB30075A0 for ; Fri, 21 Feb 2020 09:04:30 +0000 (UTC) X-FDA: 76513548300.05.ice94_7ea6fa360f009 X-HE-Tag: ice94_7ea6fa360f009 X-Filterd-Recvd-Size: 3718 Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Fri, 21 Feb 2020 09:04:30 +0000 (UTC) Received: by mail-oi1-f175.google.com with SMTP id d62so889048oia.11 for ; Fri, 21 Feb 2020 01:04:30 -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=uwpPp6lpanGdRzDNVryV+TO6Hg6osjyy/RnpORcWq6U=; b=DbrDpd0tD8ojFKPpy7SMb7xubCNYrS1wfv5dZWQTiOxuxeCkKBsVdcR7+IWUq5fIoC cMukf8I/tRMOB78RF4yxAIeXz4v50Gy5iWgJa3vT+KCUgG+RWBOSveAF10YIw3aHkTSN F7HA46Y3MqMjK16BlVs5/0wAgYztffkFK+E2tfnmWbLtvfArPLLS+O4GYcnSlTFD389r ONsnrFQDGjCnQKwQe5ZNhTXQHueDSBWDEVIywex3T2lQxS6TBYjHJBfjwZWOdUghYGia tvBRfDpQlgKjaU1+kK6FnUMqJeqRdyX8baD2UVycqxGVfyGqUlnkyS2jznEBG9eAgqeN SWWg== X-Gm-Message-State: APjAAAULt312o4eAzZj3UxpG3X8++cpT00uzBVS5pKwCCsJwNBU8ryfD gB7hDBNoaEA1hKX5/nJJ4UWsEEVT8pG3iBqTQdA= X-Google-Smtp-Source: APXvYqyPjCbsWxKosuLTEYbqkVEGs0qaK1f6mfefEZOipNIY4Z8GsHNEpXxSqf1c4k0SZwyQXXRT4CHXrbuQl3UXvys= X-Received: by 2002:aca:bfc2:: with SMTP id p185mr1149149oif.57.1582275869714; Fri, 21 Feb 2020 01:04:29 -0800 (PST) MIME-Version: 1.0 References: <20200221084910.GM20509@dhcp22.suse.cz> In-Reply-To: <20200221084910.GM20509@dhcp22.suse.cz> From: "Rafael J. Wysocki" Date: Fri, 21 Feb 2020 10:04:18 +0100 Message-ID: Subject: Re: is hibernation usable? To: Michal Hocko Cc: Luigi Semenzato , Chris Murphy , Linux Memory Management List , Linux PM 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 Fri, Feb 21, 2020 at 9:49 AM Michal Hocko wrote: > > On Thu 20-02-20 09:38:06, Luigi Semenzato wrote: > > I was forgetting: forcing swap by eating up memory is dangerous > > because it can lead to unexpected OOM kills > > Could you be more specific what you have in mind? swapoff causing the > OOM killer? > > > , but you can mitigate that > > by giving the memory-eaters a higher OOM kill score. Still, some way > > of calling try_to_free_pages() directly from user-level would be > > preferable. I wonder if such API has been discussed. > > No, there is no API to trigger the global memory reclaim. You could > start the reclaim by increasing min_free_kbytes but I wouldn't really > recommend that unless you know exactly what you are doing and also I > fail to see the point. If s2disk fails due to insufficient swap space > then how can a pro-active reclaim help in the first place? My understanding of the problem is that the size of swap is (theoretically) sufficient, but it is not used as expected during the preallocation of image memory. It was stated in one of the previous messages (not in this thread, cannot find it now) that swap (of the same size as RAM) was activated (swapon) right before hibernation, so theoretically that should be sufficient AFAICS.