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.3 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,URIBL_BLOCKED,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 994EFCA9EB3 for ; Thu, 17 Oct 2019 22:56:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3A816222CD for ; Thu, 17 Oct 2019 22:56:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="SjAkaqVl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A816222CD 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 8D8138E0005; Thu, 17 Oct 2019 18:56:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 888E48E0003; Thu, 17 Oct 2019 18:56:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 776C28E0005; Thu, 17 Oct 2019 18:56:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0075.hostedemail.com [216.40.44.75]) by kanga.kvack.org (Postfix) with ESMTP id 50A188E0003 for ; Thu, 17 Oct 2019 18:56:04 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id DBEBD82F3118 for ; Thu, 17 Oct 2019 22:56:03 +0000 (UTC) X-FDA: 76054786206.05.rice74_8c300658c392c X-HE-Tag: rice74_8c300658c392c X-Filterd-Recvd-Size: 6894 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Thu, 17 Oct 2019 22:56:03 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id j18so4118710wrq.10 for ; Thu, 17 Oct 2019 15:56:03 -0700 (PDT) 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=9rBnmh0SQQD7EZXCwG/Rmi0xjqD1Y0ThAZXFkdsY+iQ=; b=SjAkaqVlUWpxNksMr2KvBoEDX6hksckR56Ak8Yd5CTE9AGs8U5Mp3OPVW1cg0eUInR pQtHGsO8MiZVlBZP6PN6PgoShQbW0ceFcn1VKnGZH6/o5ZkgI+gSS10Rx6FU7p6GXaYV n8GxMp0AeaWH12aLWP+Xdx/UaIMz+2T7BqQBSu0rNhFpTX93+/f4g/q0x34Wx2L+63tR 8mrCxZB9PV6Fi4T+QFxbMDcWys2prqsiPfoKfNgKquWVITTygcfcurosbtiT7jNr5jU2 TQ0oxtisPoGLGLfZ+tO+0noC+nQNPKx/0FhAzp0z7aUcpblBYGq5CLshgI3YGxy6AXam JIcg== 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=9rBnmh0SQQD7EZXCwG/Rmi0xjqD1Y0ThAZXFkdsY+iQ=; b=B4R6SuC3y/E6dzYOt26wEfr3yho/AkEJbKbJEzvu4b5FkXoMEvxfphOzNJlT5NzrVJ 1jAVMgv7Xy/4Qop/lHRT8SI8jHBEnFXPGGVB8tJDZXz8V47H1J+BBup/JILPEuzl8135 v1hVNAIEQ524dZLXWyggsWo7Cg/AR3z5lZd8LvXJU6MH4bCU+V4GBoxG9BB2QHA6Z04w 5mHveDti2dU9eBOtj4VDFxSW1g0PVwDzPpZybow67u4ibu+r/cL4JhQblTiYVnYoi7sH JfKxNZ3mQJ1AegtaTq2vIBN5gX6y8nZKQ+FZHHT5RvhQVO8ysrBMUgkuHXTFzLSXXRAk QcSg== X-Gm-Message-State: APjAAAUdNHXC8C7jodsp38LhLj3BQptknilAuMlMJm+a0sXONcxdJTAp vnd1yu/+eiIH8qjk5BxKOSLCATfdjAAGVbRbCqD/Uw== X-Google-Smtp-Source: APXvYqxHqv5uhe6ktRmll2ZYbxrAZbwZeyIqcYcgbC3LJooqk9Iaqd3KZYxFkpAuQ+Hwd/x1fSfnhac10/ItdibGrSc= X-Received: by 2002:adf:e7c2:: with SMTP id e2mr4967616wrn.29.1571352961493; Thu, 17 Oct 2019 15:56:01 -0700 (PDT) MIME-Version: 1.0 References: <56319808-87dc-76ed-c1e0-9f60108e94a6@arm.com> In-Reply-To: From: Luigi Semenzato Date: Thu, 17 Oct 2019 15:55:49 -0700 Message-ID: Subject: Re: hibernation memory usage To: "Rafael J. Wysocki" Cc: James Morse , Linux Memory Management List , Bas Nowaira , Geoff Pike , 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: To make hibernation work, I have been playing with this suggestion: > Whatever doesn't fit into 50% of RAM needs to be swapped out before > hibernation. The efficiency of that depends on the swap handling code > and the underlying hardware. If that is efficient enough overall, > trying to avoid it altogether isn't going to make much of a > difference. What's a good way of swapping out 50% of RAM? I have tried playing with /proc/sys/vm/min_free_kbytes. Lowering it below MemFree forces reclaim and gets swapping started. Unfortunately the reclaim also hits file pages, so badly that the system thrashes to a grinding halt. Swappiness is already set to 100. Internally it seems that values up to 200 are valid, and I wish that the entire range was allowed, but I am not sure it would help. Right now I am playing with the production kernel, but similar situations triggered the same behavior in the Chrome OS kernels, even after internally setting swappiness to values close to 200. On Tue, Oct 8, 2019 at 1:10 PM Luigi Semenzato wrote: > > Actually, I think we only need to change the MM watermarks before > hibernation and after resume. There's a patch that will do just that: > > https://lkml.org/lkml/2013/2/17/210 > > It didn't make it into mainline (which seems kind of unreasonable, > since the watermarks themselves are based on heuristics) but shouldn't > be difficult to apply. Or are there simpler solutions? > > On Tue, Oct 8, 2019 at 9:18 AM Luigi Semenzato wrote: > > > > Yes, that makes sense, thank you. Use separate partitions for swap > > and hibernation. > > > > Normally the kernel starts swapping out when there's no reclaimable > > memory, so anon usage will be high. Do you think cranking up > > /proc/vm/swappiness would be enough to ensure that file pages stay > > over 50%? Or would you use some tricks, such as running a > > high-priority process which allocates >50% of RAM, thus forcing other > > anon pages to be swapped out, then killing that process and quickly > > hibernating before too many pages are brought back in? Or changing > > the kernel so that in the first part of hibernation we'll just swap > > stuff out? > > > > On Tue, Oct 8, 2019 at 8:39 AM Rafael J. Wysocki wrote: > > > > > > On Tue, Oct 8, 2019 at 5:26 PM Luigi Semenzato wrote: > > > > > > > > Thank you for your reply! > > > > > > > > I understand the need for saving all state, not just process/task > > > > state. But for many of the systems that could benefit from > > > > hibernation, the majority of RAM is taken by user processes (I am > > > > thinking laptops). It should be possible to copy their anonymous > > > > pages to disk more or less directly, without making an extra copy like > > > > it's done for all other pages. I am not sure what happens with kernel > > > > tasks, but they don't have anonymous pages (that I know). > > > > > > > > I am curious to know how/if hibernation is currently used in practice. > > > > It doesn't seem practical to require that user processes take less > > > > than 50% of RAM at all times. There may be special cases in which the > > > > restriction can be achieved by terminating non-essential processes > > > > before hibernating, but I don't know of any. > > > > > > > > I would also like to know how much work it might take to avoid the > > > > extra copy of the anonymous pages of frozen processes. > > > > > > Whatever doesn't fit into 50% of RAM needs to be swapped out before > > > hibernation. The efficiency of that depends on the swap handling code > > > and the underlying hardware. If that is efficient enough overall, > > > trying to avoid it altogether isn't going to make much of a > > > difference.