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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 66D60C07E99 for ; Fri, 9 Jul 2021 23:23:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C8568613C2 for ; Fri, 9 Jul 2021 23:23:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C8568613C2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8E2DC6B0073; Fri, 9 Jul 2021 19:23:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 892D96B0078; Fri, 9 Jul 2021 19:23:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 733718D0001; Fri, 9 Jul 2021 19:23:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0231.hostedemail.com [216.40.44.231]) by kanga.kvack.org (Postfix) with ESMTP id 4A6646B0073 for ; Fri, 9 Jul 2021 19:23:57 -0400 (EDT) Received: from smtpin37.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 77E5018033783 for ; Fri, 9 Jul 2021 23:23:56 +0000 (UTC) X-FDA: 78344629272.37.2C0B295 Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) by imf23.hostedemail.com (Postfix) with ESMTP id 1CA7D90000B4 for ; Fri, 9 Jul 2021 23:23:55 +0000 (UTC) Received: by mail-io1-f42.google.com with SMTP id b1so14292635ioz.8 for ; Fri, 09 Jul 2021 16:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z3wl6RUe64j2ktudh1QXGUWI+b37bnu1qQ0VROOBcwc=; b=mP4kT1ln+2gZKQefMzT9fgCMsUN+T9AvXJqutn9W9hbWQtQ9SU37TzrJzFETRl2tlS R+pydXnVQpx0K0csHb5wQRYqHuaMC5owLErCUGdUIzDBjR5yjw//hHsU8eFMocO/BYVf gQpt9eclrzW6i+cWbegfovVbWWS6g+C6f+UR8= 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=z3wl6RUe64j2ktudh1QXGUWI+b37bnu1qQ0VROOBcwc=; b=LgErPifdTovmha/dX8poVsH9Hqh14X6ZJ2BmUG68hjcefwCeRcrXuPxBc3d7aGYDVo 8maOABqNXm+TmISAICZv5jlZioN05XVVnxjHpuMvibw/kb06NiBqi04oGBFXRdxQJsmg 2SkqgQC3lL0y5+v5pUyyEsxdvAowLwWoKtLFN1UXC/gy5bu7hoRAWvJMFhIPTNwizWTW WPUzHb/ynElKcmvsMbBf8UxMqe/mQqchd7K5G2w+pPUV4OhZaLvNACHpogIXSBzLkl1Z SG4CuWpd4tN7TgAX+5nbOAhckhYV9WABf4Njlgyrdjokto0oQTYhQc0y+cORonxYbNdd L+3g== X-Gm-Message-State: AOAM531WXoHat7AfL6uVhfIDoOsUJp0r7wW6sVJMD7UUi7MrICPIBEVZ 0zWYuEtjcC95kWtyn6TZL+v417E+Rw7dkA== X-Google-Smtp-Source: ABdhPJz4CsVKWiYLbOBLNXagXy0PnkK+JsdxavJsCIgFn+btqvDWeoWDBq8y5Y/z8JaDj6GSWcKp0w== X-Received: by 2002:a5e:9309:: with SMTP id k9mr15685895iom.207.1625873035348; Fri, 09 Jul 2021 16:23:55 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com. [209.85.166.50]) by smtp.gmail.com with ESMTPSA id i5sm3841751ilc.16.2021.07.09.16.23.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 16:23:54 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id k11so14285999ioa.5 for ; Fri, 09 Jul 2021 16:23:54 -0700 (PDT) X-Received: by 2002:a05:6638:d93:: with SMTP id l19mr20497179jaj.46.1625873034167; Fri, 09 Jul 2021 16:23:54 -0700 (PDT) MIME-Version: 1.0 References: <20210709105012.v2.1.I09866d90c6de14f21223a03e9e6a31f8a02ecbaf@changeid> <20210709152024.36f650dfec4c66ef3a60a845@linux-foundation.org> In-Reply-To: <20210709152024.36f650dfec4c66ef3a60a845@linux-foundation.org> From: Evan Green Date: Fri, 9 Jul 2021 16:23:18 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] mm: Enable suspend-only swap spaces To: Andrew Morton Cc: David Hildenbrand , Pavel Machek , Alex Shi , Alistair Popple , Jens Axboe , Johannes Weiner , Joonsoo Kim , "Matthew Wilcox (Oracle)" , Miaohe Lin , Michal Hocko , Minchan Kim , Vlastimil Babka , LKML , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=mP4kT1ln; spf=pass (imf23.hostedemail.com: domain of evgreen@chromium.org designates 209.85.166.42 as permitted sender) smtp.mailfrom=evgreen@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Stat-Signature: gjyn16tdm6scxzwzu836ewucnps5iw6k X-Rspamd-Queue-Id: 1CA7D90000B4 X-Rspamd-Server: rspam01 X-HE-Tag: 1625873035-736284 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 Fri, Jul 9, 2021 at 3:20 PM Andrew Morton wrote: > > On Fri, 9 Jul 2021 10:50:48 -0700 Evan Green wrote: > > > Currently it's not possible to enable hibernation without also enabling > > 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 allow > > generic swapping to it. This region can still be wired up for use in > > suspend-to-disk activities, but will never have regular pages swapped to > > it. > > > > Swap regions with SWAP_FLAG_NOSWAP set will not appear in /proc/meminfo > > under SwapTotal and SwapFree, since they are not usable as general swap. > > > > This patch doesn't appear to set SWAP_FLAG_NOSWAP anywhere. Perhaps > there's another patch somewhere which changes the hibernation code? If > so, can we please have both patches in a series? There's no other patch, in the kernel at least. SWAP_FLAG_* is exposed to usermode, which would set it when calling swapon(2). Once this patch is accepted, I'll have to add the option into util-linux [1], so that I can use it in my init scripts. Said a different way, this patch isn't about altering how hibernate behaves, but about giving usermode the freedom to set up hibernate and swap independently. [1] https://github.com/karelzak/util-linux/blob/b4533177aeac287e0b0563cd1b9ee61bce29ee88/sys-utils/swapon.c#L710 > > Once we have a description of how this thing gets set, please let's > discuss what happens if someone tries to enable generic swap onto that > device after hibernation has set SWAP_FLAG_NOSWAP (I'm basically > guessing now). Will it work? Is there a backward-compatibility issue > here? The above paragraph maybe cleared this up. The hibernate code will still happily do I/O to any region handed to it by the swap code. That could be a region already peppered with active swap (the normal case today), or a NOSWAP region which swap otherwise stays out of (but still manages). If we did swapoff and swapon with a different setting for NOSWAP, that should all work fine, since hibernate leaves it to the swapfile code to be in charge of sector allocs/frees. There shouldn't be any backward compatibility issues because SWAP_FLAGS_VALID enforced that usermode had been keeping the unallocated bits as 0. -Evan