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 2C324C4360C for ; Tue, 8 Oct 2019 15:39:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EEE0C21721 for ; Tue, 8 Oct 2019 15:39:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EEE0C21721 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 84C808E0005; Tue, 8 Oct 2019 11:39:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7FD488E0003; Tue, 8 Oct 2019 11:39:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 711B08E0005; Tue, 8 Oct 2019 11:39:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0020.hostedemail.com [216.40.44.20]) by kanga.kvack.org (Postfix) with ESMTP id 4A7878E0003 for ; Tue, 8 Oct 2019 11:39:31 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id EDC14180AD803 for ; Tue, 8 Oct 2019 15:39:30 +0000 (UTC) X-FDA: 76021026900.29.brain38_18d6833c6e65d X-HE-Tag: brain38_18d6833c6e65d X-Filterd-Recvd-Size: 3522 Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Tue, 8 Oct 2019 15:39:30 +0000 (UTC) Received: by mail-ot1-f48.google.com with SMTP id g13so14396826otp.8 for ; Tue, 08 Oct 2019 08:39:30 -0700 (PDT) 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=xwkO+3ktpSvNGA1jiblIY+xHLOPGL+kL6G6Dfov9F2M=; b=gGhfXtvLOgnc+es4MNlAWCf3QbkAXYsj7kbRbV3pgP7gZ8TKhy7F6Lrg9WnCEs4vYe ayU77W7nDFFRLl9Q6KwC5APiqx3eGRLvrBT/+qRcedg2w69ML6ooBlH/gHAW/wZgDX+0 gUBrsV8vffjrOnhy+LJMaMBCPGaJbFLBnvaXwfzckAwFJXkdHr0z3cahYILN14qZgwQ2 w4bNdXUlieU5XMcWB12XlFI3V1M6Lr8WihMefMDyK29v8JpU31neGQqr+QBT6/xkwoBc JMIhBzJGKEfziFjg7UF3V5xFRnASaeSNmwbsFzjFMbSp3v812Ti6kCijJt/bwQRy9ibZ FzOg== X-Gm-Message-State: APjAAAUpoXmHnuVx7CCU5TCP1vGQCbx/vRNwcxin2lhl6y7GicxmrEaC 7K/MXyO00C3ijgqHAdfbecqocO+y5v3uihxmlFE= X-Google-Smtp-Source: APXvYqzpvZHDGOhIXdNjqdlCll66C1E3HQ5LKVA5WaERo79HpH2qX1Y4uqZRdd2FZ8dQ5Wv/BUAszHDPSZFFJt10zeM= X-Received: by 2002:a05:6830:1504:: with SMTP id k4mr12785579otp.262.1570549169578; Tue, 08 Oct 2019 08:39:29 -0700 (PDT) MIME-Version: 1.0 References: <56319808-87dc-76ed-c1e0-9f60108e94a6@arm.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Tue, 8 Oct 2019 17:39:18 +0200 Message-ID: Subject: Re: hibernation memory usage To: Luigi Semenzato 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 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.