Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp656818iob; Wed, 18 May 2022 10:00:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyH5Y7Or0TItqFxAKB1r192/WJbGUqHTP8mgztJBtEc7lFfarbZelsufhvslpJSXQv5xk/s X-Received: by 2002:a17:902:bb90:b0:158:a031:2ff2 with SMTP id m16-20020a170902bb9000b00158a0312ff2mr306819pls.117.1652893241491; Wed, 18 May 2022 10:00:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652893241; cv=none; d=google.com; s=arc-20160816; b=wUb1DP+BISfcDzJboIU09WD3VyLtedXY06oQugKvt4OLkqXX3EzPrbzvUDo84W3w40 KZ2xxUHEd1NtNb6rIqUyU43QaOvw0XCEMeHDYMe+rCJJS6czaXgFyDG4mlQlabP50v9g RrdRiJX766HdWq7xMVC8ekJIN0f/X2i4MZAm2XM61m+bzS0CBb9/wMowqxYmjcMTcLLZ IfW6EvpNW/FIYRWdBoDxZVQ9xID+ERT9V0ep9IhwOsBxA3yzLnFy4LfhBLBiioOfstwu qjmLT+emgC2p7zZshtafIJB1iDG+TPr7LSISo9kXprdYB+YzlqJN4F63Ofksr6U9+DFd PA1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=+RcN5J0ur4waoOrpP5dEneSJvtTucrgzrBX0vuvDNzg=; b=jUCOafBwQovbJ54TjDynmjmTIudh1nn1W6psukxM+ChBjZSTiiIXOihL7SJobolNuK +BrTYcXyl5CSTpEc4T0cQav525+Gn8LFfbJPSuuJ5MiL3m7E5uznqGM+boDR0OrpI6+E OW5bU4JAC4EsFnFB+enJYP6ZSByBBAOmOmVjMwcY+Id//kM7MuctlELBFyeqSNDdl3NF jFi/0+5HvxzDjpara/4osk9f/Tb/5fmgECzBFKLiXUww6+xecFa1iaFJjPVdcYhjJrcL 1Dx5UQwaUQ4BWO3rCvUS7gXNhM5BgpNmkpK7PDaDilJVmgqGQrAmzyoo9iRVqv5l539/ oKRg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@soleen.com header.s=google header.b="jqT/3rde"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id nb14-20020a17090b35ce00b001cb133b45f3si2920055pjb.143.2022.05.18.10.00.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 10:00:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@soleen.com header.s=google header.b="jqT/3rde"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 072AF24BD7; Wed, 18 May 2022 09:56:27 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240579AbiERQ4P (ORCPT + 99 others); Wed, 18 May 2022 12:56:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38158 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240630AbiERQz6 (ORCPT ); Wed, 18 May 2022 12:55:58 -0400 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69C491900A for ; Wed, 18 May 2022 09:55:56 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id i27so4971040ejd.9 for ; Wed, 18 May 2022 09:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+RcN5J0ur4waoOrpP5dEneSJvtTucrgzrBX0vuvDNzg=; b=jqT/3rdeSfMtEpH8kcA4/nn+EfeZSUuf8LPPqhLKI9etfw6hQt/jE/5RB9+wAn7N+Z Ehawr2Lnj8Xy/V9rEAUasHDJAEfZoSITtIIF1X9hmH3oDXIBNzCPI0/8wWj68x+PdNBs CYcJUtEpJeYfXt4e7pO3nCwPPYgiL7h53DO5Fuujh2Y6lzOqlHXACtVhqvzimDu3Oual tfhtqDL4wOAzaNxnKSix47hX+w5GxeHrTuVV+uT6Gaq249kr69g+Sjjj703raStyIOke zlWbjfU2A5GEbVZtSf4efh8q1kIlRtND9i+ESBSanFHpCYBuGyVgZ0dkOIm+//g3Sp7O /xlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+RcN5J0ur4waoOrpP5dEneSJvtTucrgzrBX0vuvDNzg=; b=VUbKK93uqGZhj/+EanO5kNPAjpaaykEQ2g69pn/5wigD0hL7EB2K9uHiAzlWx+IXbK sb/ds1r1y3XTqTtgDzJJ5/f193rsUv5+HiY09MLJYW5hBFFFPpUQfAhPNYDmwEMfEiaX CkMdTuMP6NP+CrBaucEEo5e20gksEpbqWW4M9ZWNRu7mvhq+RtPH1pwFsTxUS9jAIrTZ WZT2ipww3BBX9h8HKIPZKOXxIMaqEhWEAYQENJw4mc1SA2DJ7Bxzt/1cFg0YVq2wz3e+ Ct4yN1cost0V4ijTqVyDF1swkCjFPTu8qvqb/JblPv6Hv365di69OIIzn6PUF8ShRTRv YMzg== X-Gm-Message-State: AOAM5329/k30hDGWVDX0EOMHI/UgCRZOoUfg5nWyYjdDA6AbFEbE5cq5 bhWa/Z3FJ3KQwB2ISgLb9Hxil8HbDBeqSvA3mPUpAA== X-Received: by 2002:a17:907:1c8a:b0:6e9:2a0d:d7b7 with SMTP id nb10-20020a1709071c8a00b006e92a0dd7b7mr479411ejc.572.1652892954798; Wed, 18 May 2022 09:55:54 -0700 (PDT) MIME-Version: 1.0 References: <1652860121-24092-1-git-send-email-quic_vivekuma@quicinc.com> In-Reply-To: <1652860121-24092-1-git-send-email-quic_vivekuma@quicinc.com> From: Pasha Tatashin Date: Wed, 18 May 2022 12:55:18 -0400 Message-ID: Subject: Re: [RFC 0/6] Bootloader based hibernation To: Vivek Kumar Cc: Jonathan Corbet , Catalin Marinas , Will Deacon , Thomas Gleixner , Marc Zyngier , Jens Axboe , "Rafael J. Wysocki" , Andrew Morton , Linux Doc Mailing List , LKML , Linux ARM , linux-block , linux-pm@vger.kernel.org, linux-mm , len.brown@intel.com, Pavel Machek , paulmck@kernel.org, Borislav Petkov , Kees Cook , Muchun Song , Randy Dunlap , damien.lemoal@opensource.wdc.com, Fuad Tabba , Ard Biesheuvel , tsoni@quicinc.com, quic_psodagud@quicinc.com, quic_svaddagi@quicinc.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vivek, Interesting stuff. On Wed, May 18, 2022 at 3:49 AM Vivek Kumar wrote: > > Kernel Hibernation > > Linux Kernel has been already supporting hibernation, a process which > involves freezing of all userspace tasks, followed by quiescing of all > kernel device drivers and then a DDR snapshot is taken which is saved > to disc-swap partition, after the save, the system can either shutdown > or continue further. Generally during the next power cycle when kernel > boots and after probing almost all of the drivers, in the late_init() > part, it checks if a hibernation image is present in the specified swap > slot, if a valid hibernation image is found, it superimposes the currently > executing Kernel with an older kernel from the snapshot, moving further, > it calls the restore of the drivers and unfreezes the userspace tasks. > CONFIG_HIBERNATION and a designated swap partition needs to be present > for to enable Hibernation. > > Bootloader Based Hibernation: > > Automotive usecases require better boot KPIs, Hence we are proposing a > bootloader based hibernation restore. Purpose of bootloader based > hibernation is to improve the overall boot time till the first display > frame is seen on the screen or a camera application can be launched from > userspace after the power on reset key is pressed. This RFC patchset > implements a slightly tweaked version of hibernation in which the > restoration of an older snapshot into DDR is being carried out from the > bootloader (ABL) itself, by doing this we are saving some time > (1 second measured on msm-4.14 Kernel) by not running a > temporary kernel and figuring out the hibernation image at late_init(). I wonder where most of the time is spent? Is it initializing struct pages? Potentially we could enlighten bootloader to determine whether hibernation image is stored or not on the swap device, and change boot parameter for the kernel accordingly. The booting kernel would know from the very beginning of boot that it will eventually resume a hibernated image, and therefore skip some of initilization parts, and perhaps limit amount of memory that it initializes. > In order to achieve the same bootloader checks for the hibernation > image at a very early stage from swap partition, it parses the image and > loads it in the DDR instead of loading boot image form boot partition. > Since we are not running the temporary kernel,which would have done some > basic ARM related setup like, MMU enablement, EL2 setup, CPU setup etc, What boot loader is used? I suspect bootloader enables MMU to load the hibernated image into memory, otherwise the performance would be very poor. After the image is loaded, and prior to jumping into the entry address of loaded image the MMU is probably disabled. > entry point into hibernation snapshot image directly from bootloader is > different, on similar lines, all device drivers are now re-programming > the IO-mapped registers as part of the restore callback (which is > triggered from the hibernation framework) to bring back the HW/SW sync. > > Other factors like, read-speed of the secondary storage device and > organization of the hibernation image in the swap partition effects the > total image restore time and the overall boot time. In our current > implementation we have serialized the allocation of swap-partition's slots > in kernel, so when hibernation image is being saved to disc, each page is > not scattered across various swap-slot offsets, rather it in a serial > manner. For example, if a DDR page at Page frame number 0x8005 is > located at a swap-slot offset 50, the next valid DDR page at PFN 0x8005 > will be preset at the swap-slot offset 51. With this optimization in > place, bootloader can utilize the max capacity of issuing a disc-read > for reading a bigger chunk (~50 MBs at once) from the swap slot, > and also parsing of the image becomes simpler as it is available > contiguously. This optimization seems generic enough that it would benefit both types of resume: from bootloader and from kernel. Thanks, Pasha > > > > Vivek Kumar (6): > arm64: hibernate: Introduce new entry point to kernel > PM: Hibernate: Add option to disable disk offset randomization > block: gendisk: Add a new genhd capability flag > mm: swap: Add randomization check for swapon/off calls > Hibernate: Add check for pte_valid in saveable page > irqchip/gic-v3: Re-init GIC hardware upon hibernation restore > > Documentation/admin-guide/kernel-parameters.txt | 11 ++ > arch/arm64/kernel/hibernate.c | 9 ++ > drivers/irqchip/irq-gic-v3.c | 138 ++++++++++++++++- > include/linux/blkdev.h | 1 + > kernel/power/snapshot.c | 43 ++++++++ > kernel/power/swap.c | 12 +++ > mm/swapfile.c | 6 +- > 7 files changed, 216 insertions(+), 4 deletions(-) > > -- > 2.7.4 >