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,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 D6E9CC4360C for ; Tue, 8 Oct 2019 15:26:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 99823206C0 for ; Tue, 8 Oct 2019 15:26:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GWEjCSDj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 99823206C0 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 410088E0005; Tue, 8 Oct 2019 11:26:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C0FC8E0003; Tue, 8 Oct 2019 11:26:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D6B68E0005; Tue, 8 Oct 2019 11:26:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id 0C90A8E0003 for ; Tue, 8 Oct 2019 11:26:48 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id B04466882 for ; Tue, 8 Oct 2019 15:26:47 +0000 (UTC) X-FDA: 76020994854.19.nail16_3b43263fe2532 X-HE-Tag: nail16_3b43263fe2532 X-Filterd-Recvd-Size: 5609 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Tue, 8 Oct 2019 15:26:47 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id v8so19929583wrt.2 for ; Tue, 08 Oct 2019 08:26:47 -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=J2oIehGoOMVCceq4ryG/0Q4N7vU0pUYa7bMlMOgxii4=; b=GWEjCSDj8XMob/ZTZqi3m004svLDmGi8+jtceuXNDkMOg2teXgVLfb/Mzsrw9EK49F zHu3I9w7bqAZPIgw+1sy0Yuto3Le2BzSZhfPRtFlqKW/8Xtsk0ZIf23Yyo+jxEUlH5bY IfV3pkkDct++s6IOuVoRcfSZjtbG0ZaljMxR4jJYZmQSofN14H219IomARDYTQu/3RpM qdUsW9yZQ53MicCg7QT9mSiZ3COLx6q+HAz1paefVyxkhmWA2qxLlOxLWnzLSTeLTZHr U+swRh+SKfXj8vRnKG23pmDJHFzTrdRWLEl6L8IykeJmOu0tAntnARwBIm2sadw0qzpD FCWA== 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=J2oIehGoOMVCceq4ryG/0Q4N7vU0pUYa7bMlMOgxii4=; b=NUayOBGwbk1k915+w4T8tzESFh9Pfc6TgyQTycK2AqvYqlgDXiCHRn3/DrD32drExF QhgC5O8LI1cSkCR/M5e5e7/CzWuzrvIL6PGy9+T6WBRi4labYW5hyEkxuJN0WEgN8C1l 2XwnAc5uddSzrvxA1YCjh4ZrK9XFHkpACdhLYG5gdjigj2G75ZwI17eGbwdZ1nCT/A1l 0kRlszhkJ3aQ1WQdttKD1T7vzaF/AmNWR38Mv5Ipwnq2bb+KujlmOFdGssPNj55wqbPj s2svidoTOmo4rnn9wHBTzWoAOpin8ofC7es1w73wsiUEv97u66t40/fcW8/GszxGajHe JfQg== X-Gm-Message-State: APjAAAULsAI33alQNtYrjfgBd7J3OHF7BQbPDc7hrmKejsUA/5+2/7E4 IujpQpRd55lo4JkE9/l09mW+ciRWWKTFH0KFNR2gkA== X-Google-Smtp-Source: APXvYqwtq3DpzKGtSTLI1nWQJTAa6oyJxH+FwoM21U/hTFWHGY4k1BlsSrMieCwYB8Y4HaM95gIJbcdC/YJC0XbKbJs= X-Received: by 2002:adf:db04:: with SMTP id s4mr3716759wri.80.1570548405344; Tue, 08 Oct 2019 08:26:45 -0700 (PDT) MIME-Version: 1.0 References: <56319808-87dc-76ed-c1e0-9f60108e94a6@arm.com> In-Reply-To: <56319808-87dc-76ed-c1e0-9f60108e94a6@arm.com> From: Luigi Semenzato Date: Tue, 8 Oct 2019 08:26:33 -0700 Message-ID: Subject: Re: hibernation memory usage To: James Morse Cc: Linux Memory Management List , Bas Nowaira , Geoff Pike , linux-pm@vger.kernel.org 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: 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. Thanks! On Tue, Oct 8, 2019 at 3:33 AM James Morse wrote: > > Hi Luigi, > > (CC: +linux-pm mailing list) > > On 03/10/2019 18:16, Luigi Semenzato wrote: > > I am working on a project that uses hibernation, and we've noticed occasional failures > > with "echo disk > /sys/power/state" returning ENOMEM. I added some logging and noticed > > that the failures seem to correlate with total anonymous pages being approximately 1/2 of > > total RAM. The allocation strategy isn't explicitly documented and the code is a bit > > tricky (as usual), but I am getting the sense that a copy of the entire RAM in use is made > > prior to saving it to disk. Is it the case then that hibernation is guaranteed to fail if > > anon memory is more than 50% of RAM? > > I'm pretty sure it is. If 50% of memory needs saving, you can't create a snapshot of it. > > > > Since tasks are frozen, that memory cannot change> and the copy seems redundant (except it probably makes things simpler). > > Tasks aren't the only thing changing memory. Hibernate save/restores the entire system, > including the kernel data and text. (what happens if a task is waiting for a syscall to > complete?) > > > Hibernate needs a snapshot of memory, and the disk drivers, block layer etc need to write > to memory (and allocate it) in order to get their work done. > > To work with this, hibernate's create_image() stops secondary CPUs and suspends all > devices. Now that only hibernate is running, it calls swsusp_arch_suspend() which then > call swsusp_save(). This creates the snapshot of memory. > > Once this is done, devices are thawed, and hibernate() goes on to call swusp_write() to > write the snapshot to disk. Finally, processes are thawed. > > (create_image() is called by hibernation_snapshot() from hibernate()). > > > If you don't need to save/restore the kernel state, you might not need hibernate at all. > > > Thanks, > > James