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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 1DA48C07E9A for ; Wed, 14 Jul 2021 07:51:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B8B3061360 for ; Wed, 14 Jul 2021 07:51:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B8B3061360 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F2BB46B0088; Wed, 14 Jul 2021 03:51:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EDBBD6B008C; Wed, 14 Jul 2021 03:51:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D568D6B0092; Wed, 14 Jul 2021 03:51:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0189.hostedemail.com [216.40.44.189]) by kanga.kvack.org (Postfix) with ESMTP id B0D536B0088 for ; Wed, 14 Jul 2021 03:51:19 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 919141F855 for ; Wed, 14 Jul 2021 07:51:18 +0000 (UTC) X-FDA: 78360423036.15.56B47FB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf27.hostedemail.com (Postfix) with ESMTP id 47EFC70000A8 for ; Wed, 14 Jul 2021 07:51:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626249077; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uIAamLRB+l2EUOb7y0yMXzaGCmbBtLAf0vymHfStw1I=; b=TUYQtGzSvHAI0LrH/8bhwoAKLF7W7Eksfu6rmS+0QGkkT/iMOpzHvozC/QyGVuPdmhQ3OB jS4fbtL9CMZ6O4B37q1oJ/gzimaMwSWssFwwHOHKhnt1qsvGGB7SSK9NqKPrQKXsjga15S 0yXpWGPUc3qJYG/rP23nf//i9PG9q1A= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-579-NnsSdo8BP6GSs8NX-lSC2w-1; Wed, 14 Jul 2021 03:51:16 -0400 X-MC-Unique: NnsSdo8BP6GSs8NX-lSC2w-1 Received: by mail-wr1-f70.google.com with SMTP id 32-20020adf82a30000b029013b21c75294so1028570wrc.14 for ; Wed, 14 Jul 2021 00:51:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=uIAamLRB+l2EUOb7y0yMXzaGCmbBtLAf0vymHfStw1I=; b=SV72D1R9EM1yj4IWYp/CRvQgGVDPSJncQlUQ9Vrla3YT0wLOf46vJ7sTlyJdkT309L 1COHfz6vK4eNq3oZRs3S3uLEOmpWx8ovKkwMiXiVgy8woGz33vHuyPYT3yFwOf3LLvYw grW3DLIN7Jbjs/sw4smHF07Rx3qpT5Dg7kCfmNJcKmVWsMQavuFIJLWMBpgrlN7YLgpT bTs4gc3U4jPd7HWqZz4SRX1EQn8pwKWi7QLveRf59HSxYlrbu6cpkQErotc/xZ1Dt438 aRpBBY7cM9rfgdTJfcpikqRQpz7plysRb6PVkuy/ubDAGu1Sgx3lSTofJKDf6uolk0Pa ywqg== X-Gm-Message-State: AOAM533Dry+j2dDVjKSGFWFOocIBljnWzqj9p7+Qw2lOECOdaGIM0S3t eLKy4aQpym+mozp7w6UC8gaAgv9UawzCb4rmxNaEHLi+RRO0gictX7vhQTjWDvwglNvAR+prUoW tkWjw5IcEj04= X-Received: by 2002:adf:fbce:: with SMTP id d14mr11323566wrs.236.1626249075562; Wed, 14 Jul 2021 00:51:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzGhZcK0OQbvhqYsVxTMC9Y+/0J9nJNJEEX3Vn4NXbRA/BUl43hnjxQYA6Zs6sMdkR9NApeEA== X-Received: by 2002:adf:fbce:: with SMTP id d14mr11323536wrs.236.1626249075294; Wed, 14 Jul 2021 00:51:15 -0700 (PDT) Received: from [192.168.3.132] (p5b0c60d5.dip0.t-ipconnect.de. [91.12.96.213]) by smtp.gmail.com with ESMTPSA id f7sm4365345wml.35.2021.07.14.00.51.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jul 2021 00:51:14 -0700 (PDT) To: Michal Hocko Cc: Evan Green , Andrew Morton , Pavel Machek , Alex Shi , Alistair Popple , Jens Axboe , Johannes Weiner , Joonsoo Kim , "Matthew Wilcox (Oracle)" , Miaohe Lin , Minchan Kim , Vlastimil Babka , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org References: <20210709105012.v2.1.I09866d90c6de14f21223a03e9e6a31f8a02ecbaf@changeid> <30dddfb1-388c-a593-0987-73e821216da9@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2] mm: Enable suspend-only swap spaces Message-ID: Date: Wed, 14 Jul 2021 09:51:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 47EFC70000A8 X-Stat-Signature: iqruz9jx8q6dcp9rfe1ky6te51wgnc56 Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TUYQtGzS; spf=none (imf27.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1626249078-20045 Content-Transfer-Encoding: quoted-printable 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 14.07.21 07:43, Michal Hocko wrote: > On Mon 12-07-21 09:41:26, David Hildenbrand wrote: >> On 12.07.21 09:03, Michal Hocko wrote: >>> [Cc linux-api] >>> >>> On Fri 09-07-21 10:50:48, Evan Green wrote: >>>> Currently it's not possible to enable hibernation without also enabl= ing >>>> generic swap for a given swap area. These two use cases are not the >>>> same. For example there may be users who want to enable hibernation, >>>> but whose drives don't have the write endurance for generic swap >>>> activities. >>>> >>>> Add a new SWAP_FLAG_NOSWAP that adds a swap region but refuses to al= low >>>> generic swapping to it. This region can still be wired up for use in >>>> suspend-to-disk activities, but will never have regular pages swappe= d to >>>> it. >>> >>> Could you expand some more on why a strict exclusion is really >>> necessary? I do understand that one might not want to have swap stora= ge >>> available all the time but considering that swapon is really a light >>> operation so something like the following should be a reasonable >>> workaround, no? >>> swapon storage/file >>> s2disk >>> swapoff storage >> >> I'm certainly not a hibernation expert, but I'd guess this can also be >> triggered by HW events, so from the kernel and not only from user spac= e >> where your workaround would apply. >=20 > Is there anything preventing such a HW event doing the equivalent of th= e > above? >=20 Let's take a look at hibernate() callers: drivers/mfd/tps65010.c: calls hibernate() from IRQ contex, based on HW event kernel/power/autosleep.c: calls hibernate() when it thinks it might be a good time to go to sleep kernel/power/main.c: calls hibernate() triggered by userspace kernel/reboot.c: calls hibernate() triggered by userspace So on two paths, hibernate() is not under user space control and the=20 sequence you propose does not apply. The kernel itself has no idea which=20 swap space to activate before hibernating, that's a user space decision.=20 And without this patch, user space cannot communicate that decision to=20 the kernel without eventually also swapping. However, I assume in most cases (e.g., ACPI events, power button=20 pressed, ...) we always notify user space, which in return decides which=20 action to take. Doing it under kernel control is more of a corner case I=20 guess, so I do wonder if we really care about these setups. Anyhow, the proposal here does not sound completely crazy to me,=20 although it's unfortunate how we decided to mangle hibernation and=20 swapping into the same mechanism originally; a different interface to=20 active "hibernation only backends" would be cleaner than doing a "swapon=20 ..." without swapping. However, that will require much more work and I=20 am not sure if it's worth it ... --=20 Thanks, David / dhildenb