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 610EBCA9EA0 for ; Sat, 19 Oct 2019 01:49:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0B119222C6 for ; Sat, 19 Oct 2019 01:49:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="sWtHEsB6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B119222C6 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 9093A8E0005; Fri, 18 Oct 2019 21:49:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B97A8E0003; Fri, 18 Oct 2019 21:49:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A8B98E0005; Fri, 18 Oct 2019 21:49:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0194.hostedemail.com [216.40.44.194]) by kanga.kvack.org (Postfix) with ESMTP id 5C01E8E0003 for ; Fri, 18 Oct 2019 21:49:20 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 0B4941800172C for ; Sat, 19 Oct 2019 01:49:20 +0000 (UTC) X-FDA: 76058851680.13.hill26_6e885dfb5213b X-HE-Tag: hill26_6e885dfb5213b X-Filterd-Recvd-Size: 7549 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Sat, 19 Oct 2019 01:49:19 +0000 (UTC) Received: by mail-wm1-f68.google.com with SMTP id v17so7688112wml.4 for ; Fri, 18 Oct 2019 18:49:19 -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=8gx1BmqM46WdJVc4Gf2BxUzi9XfzcFz0ScvsTxkV+8I=; b=sWtHEsB6ul2jGRYR95HNkgQoUVKB4s+E8M/EmCQ/mq+3HRPpW+v79wzHvWZ+FW+AiO KMlg1AKe9UKxsnsQFHHn5oYiHKBWhrHxQ+jeapdmKm8bjSP8mG3F/ECxjHha4quQoP03 wdgYxGIBd3fIr5sCB1P4QR8PTCjUuwQWXDlIcc5WR8lO7DWLRCE3Jn25mPZqfQIx44St JydaJ2QemvFueVrK0yyLv2Zf0PjVkdqNfq1fmsYpfSfUV0mGCM0T4y5+QVQfm1+4KPpB NYutBMFYKmDNT0RRmpJeNX1Wk0js7PE27uLo72LrOh00ruH0slBx+MFSGMeKEB7RwTqm JXfw== 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=8gx1BmqM46WdJVc4Gf2BxUzi9XfzcFz0ScvsTxkV+8I=; b=e68+ZgrIgm4xhsuA52eEKOoLXFMNDs8LK8xza00b3W6dNHQFjdBgcKAvStq0gC8RaZ NXF/f2lq0QU4vF4bxsaip7gqyKIVE5AEvbkVVsOdmEtX76jbiQGk8WESTGRGdriWR941 HHDbLRQ1OHSo4QfUigQrjJo9auyYjVC87gY1bR8OF6qAm+bstykgaOnsDPV2pmpHxfsv v/IpFwPkU77y2oXAFAWaBVYJiMArQUUGr1zJf29gaZkd3xFGuib510xTbS20UfcptOtY /gOT++8+Nbc+TSooO90p6DVDf8hDEsBuN3oCO2oom/9iDxRZGl8l1P+/CstaCV78nLr5 lRPA== X-Gm-Message-State: APjAAAUZtqktjZUmE6dl8vMryJ3pY8hIOTcAgeq8rpuO61y8rF9zvDZO 0oDR/3wbNT7vlm5tWlIT43Ra6IdG4w8SjrLFwQeFDg== X-Google-Smtp-Source: APXvYqy7WBGcfW3iDAqhA0uZlzezvPdjzAZLfmyPQhHNEhxHBnO2KxjQSw3PzpXH6Jga9rlV3Vzuj4YTyNZMpuUl2Y0= X-Received: by 2002:a1c:7d08:: with SMTP id y8mr4758419wmc.160.1571449757594; Fri, 18 Oct 2019 18:49:17 -0700 (PDT) MIME-Version: 1.0 References: <56319808-87dc-76ed-c1e0-9f60108e94a6@arm.com> In-Reply-To: From: Luigi Semenzato Date: Fri, 18 Oct 2019 18:49:04 -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: On Thu, Oct 17, 2019 at 3:55 PM Luigi Semenzato wrote: > > 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. One more data point: playing with min_free_kbytes is flakey: it can cause OOM-kills even when I increase it slowly (so that I don't completely destroy the file RSS) and there is plenty of swap space available. Not sure why. Is there perhaps a way of achieving this using the userland suspend API? If there is, I am not able to see it. Thanks! > 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.