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 6F85BC4360C for ; Tue, 8 Oct 2019 16:18:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 27A91206C2 for ; Tue, 8 Oct 2019 16:18:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="MFiJsDlq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 27A91206C2 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 C4EAB8E0006; Tue, 8 Oct 2019 12:18:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BFDB68E0003; Tue, 8 Oct 2019 12:18:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AEC948E0006; Tue, 8 Oct 2019 12:18:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0045.hostedemail.com [216.40.44.45]) by kanga.kvack.org (Postfix) with ESMTP id 8D4D78E0003 for ; Tue, 8 Oct 2019 12:18:15 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 38E6E6109 for ; Tue, 8 Oct 2019 16:18:15 +0000 (UTC) X-FDA: 76021124550.27.soda09_4802332ae4841 X-HE-Tag: soda09_4802332ae4841 X-Filterd-Recvd-Size: 5016 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Tue, 8 Oct 2019 16:18:14 +0000 (UTC) Received: by mail-wm1-f50.google.com with SMTP id r19so3841945wmh.2 for ; Tue, 08 Oct 2019 09:18:14 -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=fq39f35/DAgMRpFzxjAJpDDxpwFQXNEdjkCjZJk2WaE=; b=MFiJsDlqQpsJ7yc1KIekhPsKXUGVrQLR8QCHMXLz0rNsjXV9yLXnleym3LN7q9PM5/ U7vxkx6EBY7fAFZFHdZOBPBBKcWvn9dY6k2tqofLfqVKYX36PRl2lk+mb88hdzMEG8hK coK1QJyE++VVUjY/6p38xFY7azdUlWRmSd5dLMMLq4kDH8toCP0q3I9tAxRfJm5WusXE 4va27WxziGwOUcjU4kMjLvyJjhhjzXjcVNcKtn7RGs51nUM37jIehTogenUxjJYNaLO4 m1qPB0AVKx/49/g8ylSWy/Bh0Wzidw3sfIcypzeHP3EfRhUV8h0dqRT5ilWlKDOjV86Z AlZw== 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=fq39f35/DAgMRpFzxjAJpDDxpwFQXNEdjkCjZJk2WaE=; b=rw8JTnoeko6mxrfe6X31uQA4ldOUab4KTzMv10eXqALwrt5HZEC/+K8If/tTPTnmv1 2jv9u2Ax3C+jYI7iPrN0YDDmGl4A2R/lf1j7yooJYgg+Npchpj4cO8T4tt/k2l65fdMN wKS90qYIzq5CW11GvDvH5Yw6FAqRIKefHSokbwKFM/la2Ex8xIUcHWsOGHF1ufHmKzkK /yVlB2AIb9O18hVUlwykg/ehSj7iFaFdGrZ69txqdrw8C5ZSJ5zp4oJkual4SGfwBKpk GsWQOgjv9DofLuFER74nLeV8OqxOO7bkcpUrJeUv2dms3lopHTwPucpQP/UhWQHwH113 GH8A== X-Gm-Message-State: APjAAAX+ADvfOKe4i+oYrQzG0qrBEuSryHIkTn60hW83VGzDuFqglSAn fKjmZ8/l3QeRRQnym6mqAGW3Llxp1K+NHb16g9UGpw== X-Google-Smtp-Source: APXvYqxsu6hqSZm4NEsa823qu9Zop5Q8ujIDa+7yw5bajhKeIQZYNvOBuV3urJTh7zAUqKF6ux+s+qJmJWuumc9FSmc= X-Received: by 2002:a7b:c44d:: with SMTP id l13mr4206355wmi.160.1570551493022; Tue, 08 Oct 2019 09:18:13 -0700 (PDT) MIME-Version: 1.0 References: <56319808-87dc-76ed-c1e0-9f60108e94a6@arm.com> In-Reply-To: From: Luigi Semenzato Date: Tue, 8 Oct 2019 09:18:01 -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.006303, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.