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 0BCD8C11D1B for ; Thu, 20 Feb 2020 19:45:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A4372206F4 for ; Thu, 20 Feb 2020 19:45:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="qp7sI58v" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A4372206F4 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 1B0486B0007; Thu, 20 Feb 2020 14:45:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1602F6B0008; Thu, 20 Feb 2020 14:45:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 077876B000A; Thu, 20 Feb 2020 14:45:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E35D66B0007 for ; Thu, 20 Feb 2020 14:45:00 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A9422180AD81F for ; Thu, 20 Feb 2020 19:45:00 +0000 (UTC) X-FDA: 76511533560.02.curve36_83046b724ac08 X-HE-Tag: curve36_83046b724ac08 X-Filterd-Recvd-Size: 5956 Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Thu, 20 Feb 2020 19:45:00 +0000 (UTC) Received: by mail-io1-f67.google.com with SMTP id h8so6066365iob.2 for ; Thu, 20 Feb 2020 11:45:00 -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=KKqN/iwJgPWQoJZqKIuSVEOU9r8dfik/qZjVm2BXQc8=; b=qp7sI58vKnxDEgfQm4XoQP6FZPCPQS5IP4OpMn+j72GBlwxd2aNcpvX8/CFJ0HQ14+ rm4iEzfpboU/cipjMf7aj64przNVjkw4spKqiM1lbd7J4mDjKT43xe0FICJh5qHGYC8E f5mJA7abjqmxDLwAkKb0gwJv+xqcR7sqGSgTcklkSy8mwF410jZpWewEwbWnN8Sx+sWK UNzAzDv0/2c75KmMJUWYy1jHf46/G0BeMJJw5m2tFgydqvj6dRO54k1HEQNxLY1CIvrz 5Ts3muKbj2NMfK65NspiAOPM5yAg26hfYlEwsbHJkC4/RAuug//HaPzceJb6GrhvABvv CP/Q== 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=KKqN/iwJgPWQoJZqKIuSVEOU9r8dfik/qZjVm2BXQc8=; b=bkaWjhxef4gMXIeWEZH7l2IgOnUpXgYR8Ztspjb7odsH7XyXyh+vg2NNZjGWeIA0xl r2ecWFicKIlhcqf7/pAtxbvQZ5rlQUxOnr/40clvTUmiArhzlGjmL2SGP/RjnLjLmpLU pjkN6CrvllrBpkeSfH6YZSAW7gF+SQZFnsisVFtdnLGFAwY+I2LhXLkO7NPy7EjmxExR EP0xL93zE1I+GUquBW/v0H6uPtTJ2JDW945mdXiC3b/NGLgC9Z0qIgB9+mFkP5BcIYHS 3bqxxLJMuq9yy7Nva9DZqQwb4uNCP83ZPwQtIVir2GOtnLVNh0JWnnIgpNP0U9sG7BIB CmBg== X-Gm-Message-State: APjAAAU7cRlIQQRrgwqx6If4mVVEG2kDa5wo3HovuZx5wbhnN0NrJP0w i+0zFFTGVWfGoBG1LWnWru7+GuNLdIv19C+i/gGyDqL0Ur0= X-Google-Smtp-Source: APXvYqzscVpFdCqhjUQe92nHPxDt4DpukOfwNBi734w8X8KKwFVbjP7izMIRThwIuJid5Dra6O7Kck2EJITgazEU13c= X-Received: by 2002:a5d:8952:: with SMTP id b18mr26111252iot.40.1582227899224; Thu, 20 Feb 2020 11:44:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Luigi Semenzato Date: Thu, 20 Feb 2020 11:44:48 -0800 Message-ID: Subject: Re: is hibernation usable? To: Chris Murphy Cc: 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 Thu, Feb 20, 2020 at 11:09 AM Chris Murphy wrote: > > On Thu, Feb 20, 2020 at 10:16 AM Luigi Semenzato wrote: > > > > I think this is the right group for the memory issues. > > > > I suspect that the problem with failed allocations (ENOMEM) boils down > > to the unreliability of the page allocator. In my experience, under > > pressure (i.e. pages must be swapped out to be reclaimed) allocations > > can fail even when in theory they should succeed. (I wish I were > > wrong and that someone would convincingly correct me.) > > What is vm.swappiness set to on your system? A fellow Fedora > contributor who has consistently reproduced what you describe, has > discovered he has vm.swappiness=0, and even if it's set to 1, the > problem no longer happens. And this is not a documented consequence of > using a value of 0. I am using the default value of 60. A zero value should cause all file pages to be discarded before any anonymous pages are swapped. I wonder if the fellow Fedora contributor's workload has a lot of file pages, so that discarding them is enough for the image allocator to succeed. In that case "sync; echo 1 > /proc/sys/vm/drop_caches" would be a better way of achieving the same result. (By the way, in my experiments I do that just before hibernating.) > > I have a workaround in which I use memcgroups to free pages before > > starting hibernation. The cgroup request "echo $limit > > > .../memory.limit_in_bytes" blocks until memory usage in the chosen > > cgroup is below $limit. However, I have seen this request fail even > > when there is extra available swap space. > > > > The callback for the operation is mem_cgroup_resize_limit() (BTW I am > > looking at kernel version 4.3.5) and that code has a loop where > > try_to_free_pages() is called up to retry_count, which is at least 5. > > Why 5? One suspects that the writer of that code must have also > > realized that the page freeing request is unreliable and it's worth > > trying multiple times. > > > > So you could try something similar. I don't know if there are > > interfaces to try_to_free_pages() other than those in cgroups. If > > not, and you aren't using cgroups, one way might be to start several > > memory-eating processes (such as "dd if=/dev/zero bs=1G count=1 | > > sleep infinity") and monitor allocation, then when they use more than > > 50% of RAM kill them and immediately hibernate before the freed pages > > are reused. If you can build your custom kernel, maybe it's worth > > adding a sysfs entry to invoke try_to_free_pages(). You could also > > change the hibernation code to do that, but having the user-level hook > > may be more flexible. > > Fedora 31+ now uses cgroupsv2. In any case, my use case is making sure > this works correctly, sanely, with mainline kernels because Fedora > doesn't do custom things with the kernel. > > > > -- > Chris Murphy