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=-7.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, 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 05CEBC6377D for ; Thu, 22 Jul 2021 18:08:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 55862634E6 for ; Thu, 22 Jul 2021 18:08:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 55862634E6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id B4C6B6B006C; Thu, 22 Jul 2021 14:08:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AFD586B0071; Thu, 22 Jul 2021 14:08:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9EB096B0072; Thu, 22 Jul 2021 14:08:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) by kanga.kvack.org (Postfix) with ESMTP id 8222F6B006C for ; Thu, 22 Jul 2021 14:08:17 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2DF43180AD83E for ; Thu, 22 Jul 2021 18:08:17 +0000 (UTC) X-FDA: 78391008234.38.687015C Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) by imf17.hostedemail.com (Postfix) with ESMTP id E4F52F002CB8 for ; Thu, 22 Jul 2021 18:08:15 +0000 (UTC) Received: by mail-io1-f52.google.com with SMTP id k11so7407286ioa.5 for ; Thu, 22 Jul 2021 11:08:15 -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=XCe9Px5IbYx9WoehfjTAmfQBvNYKzF4HFGZVPEMv3Dw=; b=bTcBVSLQGMhrpoZxQ5uU5iBAxtON1Fb8TJYSzfATlcDOrA52tzAbADe6fEnjQ4M1t4 vtIxTuWPNU6xUPZTCnBBpPdhpSyNLdQuBeYti8gELBuBnp+9OMVxMLmuCnqpY94Z7hoy 4wioJg6a8kbT5fXAJhoUuorTKFv2ViM5xfS7I= 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=XCe9Px5IbYx9WoehfjTAmfQBvNYKzF4HFGZVPEMv3Dw=; b=CZY94KZGT4dyGF5qr0KukGZJoxc1tUEa8vmECrVf/BUkYU+AX6tu57Jx4xtmtwJ+LK xEY7ScTbfPS99w68alqRvk9P2xzlHczWPlu727PeIA6r1uW94XFTGuYfSjQzyjkVSPGY 1hQUUwjpNljQn3ibVE/WjaqdQhUJVK8YPNOkywSKww/N3JvGET0VTGwnVFoFBPTNol1G A+1jxPm3qXiw9xzK5F+7c0N8DERfk9UxfJznq09nUMGg1I6gzt7LNypmyv6q8nWdBASk hK03gMza64Y5NxQa/TGggHcuMSM58ksK7FZScH/udU2P17spAEeWOHv60v/Wi6nse4rC UhHQ== X-Gm-Message-State: AOAM530XI1acbJ1BP8dLqZyx3US7sU6EZnY8F2LjuCw5DduK7u/GCSKE vfCVCGGKMOkUKrrdFalIOaM2Vmoy3UP8uQ== X-Google-Smtp-Source: ABdhPJzXpRDR8S0VGRhVhWJO4uEgciohV5ZxwoqesgIxKKHdsdZ4kcsOMlRu7ThhiFCTTLy0DzhKkQ== X-Received: by 2002:a02:774a:: with SMTP id g71mr657190jac.137.1626977295021; Thu, 22 Jul 2021 11:08:15 -0700 (PDT) Received: from mail-il1-f172.google.com (mail-il1-f172.google.com. [209.85.166.172]) by smtp.gmail.com with ESMTPSA id b25sm16683445ios.36.2021.07.22.11.08.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jul 2021 11:08:14 -0700 (PDT) Received: by mail-il1-f172.google.com with SMTP id w1so6191438ilg.10 for ; Thu, 22 Jul 2021 11:08:14 -0700 (PDT) X-Received: by 2002:a05:6e02:1aa2:: with SMTP id l2mr662668ilv.224.1626976892898; Thu, 22 Jul 2021 11:01:32 -0700 (PDT) MIME-Version: 1.0 References: <20210721143946.v3.1.I09866d90c6de14f21223a03e9e6a31f8a02ecbaf@changeid> In-Reply-To: From: Evan Green Date: Thu, 22 Jul 2021 11:00:56 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] mm: Enable suspend-only swap spaces To: David Hildenbrand Cc: Andrew Morton , linux-api@vger.kernel.org, Michal Hocko , Pavel Machek , Alex Shi , Alistair Popple , Johannes Weiner , Joonsoo Kim , "Matthew Wilcox (Oracle)" , Miaohe Lin , Minchan Kim , Suren Baghdasaryan , Vlastimil Babka , LKML , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E4F52F002CB8 X-Stat-Signature: 879j8aefz4scn4ucmd3jmyur8u5jr4h1 Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=bTcBVSLQ; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf17.hostedemail.com: domain of evgreen@chromium.org designates 209.85.166.52 as permitted sender) smtp.mailfrom=evgreen@chromium.org X-HE-Tag: 1626977295-69574 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 Thu, Jul 22, 2021 at 12:12 AM David Hildenbrand wrote: > > On 21.07.21 23:40, 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. Swap and hibernate also have different security/integrity > > requirements, prompting folks to possibly set up something like block-level > > integrity for swap and image-level integrity for hibernate. Keeping swap > > and hibernate separate in these cases becomes not just a matter of > > preference, but correctness. > > > > 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. This flag will be passed in by utilities like swapon(8), usage would > > probably look something like: swapon -o noswap /dev/sda2. > > Just a minor comment, I'd call it rather SWAP_FLAG_HIBERNATE_ONLY and > SWAP_FLAG_HIBERNATE_ONLY -- that calls the child by its name. I went back and forth on this too. It seemed pretty close to toss-up to me. I went with NOSWAP ultimately because it seemed more closely tied to what the flag was actually doing, rather than building in my one expected use case into the name. In some world years from now where either hibernate has diverged, been deleted, or maybe some new usage has been invented for swap space, the NOSWAP name felt like it had a better chance of holding up. The argument is weak though, as these features are pretty well cast in stone, and the likelihood of any of those outcomes seems low. I can change it if you feel strongly, but would probably keep it as-is otherwise. > > I think some other flags might not apply with that new flag set, right? > For example, does SWAP_FLAG_DISCARD_ONCE or SWP_AREA_DISCARD still have > any meaning with the new flag being set? > > We should most probably disallow enabling any flag that doesn't make any > sense in combination. Good point, I can send a followup patch for that. From my reading SWAP_FLAG_DISCARD and SWAP_FLAG_DISCARD_ONCE are still valid, since the discard can be run at swapon() time. SWAP_FLAG_PREFER (specifying the priority) doesn't make sense, and SWAP_FLAG_DISCARD_PAGES never kicks in because it's called at the cluster level. Hm, that sort of seems like a bug that freed hibernate swap doesn't get discarded. I can disallow it now as unsupported, but might send a patch to fix it later. > > Apart from that, I'd love to see a comment in here why the workaround > suggested by Michal isn't feasible -- essentially a summary of what we > discussed. Ah sorry, I had tried to clarify that in the commit text, but didn't explicitly address the workaround. To summarize, the workaround keeps generic swap out of your hibernate region... until hibernate time. But once hibernate starts, a lot of swapping tends to happen when the hiber-image is allocated. At this point the hibernate region is eligible for general swap even with the workaround. The reasons I gave for wanting to exclusively steer swap and hibernate are SSD write wearing, different integrity solutions for swap vs hibernate, and our own security changes that no-op out the swapon/swapoff syscalls after init. > > I had a quick glimpse and nothing jumed at me, no mm/swapfile.c expert, > though :) Thanks David! -Evan > > > > -- > Thanks, > > David / dhildenb >