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.3 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 16AE9C6377D for ; Thu, 22 Jul 2021 07:12:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 99FED6135B for ; Thu, 22 Jul 2021 07:12:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 99FED6135B 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 D44D66B006C; Thu, 22 Jul 2021 03:12:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CF4E46B0071; Thu, 22 Jul 2021 03:12:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BBB686B0072; Thu, 22 Jul 2021 03:12:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0204.hostedemail.com [216.40.44.204]) by kanga.kvack.org (Postfix) with ESMTP id A0B3D6B006C for ; Thu, 22 Jul 2021 03:12:52 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 4A6AB2196F for ; Thu, 22 Jul 2021 07:12:52 +0000 (UTC) X-FDA: 78389356584.13.5700B47 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf05.hostedemail.com (Postfix) with ESMTP id DEAEF500472B for ; Thu, 22 Jul 2021 07:12:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626937971; 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=lie9E7QLfh8t44ZxpePc74B/WhWJVlmlTUrVnVd6Siw=; b=fZx+smdn9d0lBTCQQwjc4eiPQZVJ28lM2py8S9Ihgz1X1sPJbjSzKWnSyZsrLuqPUX1t2h GVMlrc7+/h1tf5hw8fcAkOlyXZ+nBa5VBILrQ4tq6bRoZezx8323qFjl70OmFraZYN+BYP Z2cUEKs0BVSbu474crvePF7s5MtzcSQ= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-473-m_jsDlmyPoSws38IMDTG5w-1; Thu, 22 Jul 2021 03:12:47 -0400 X-MC-Unique: m_jsDlmyPoSws38IMDTG5w-1 Received: by mail-wm1-f72.google.com with SMTP id i8-20020a1c54080000b02901e46e4d52c0so341899wmb.6 for ; Thu, 22 Jul 2021 00:12:47 -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=lie9E7QLfh8t44ZxpePc74B/WhWJVlmlTUrVnVd6Siw=; b=g3Z/sOqeEipOTrpGx0SfAs9F2xKceBrx/tpLOzs5rUCJ7bdB7N5Ur46n2k6IH7i0kR O1gfi2tL/cMhoJDcuDBOVVbBexfjH8/TByMGOLQt9CdXMayHaK++dYwS5VJuMN9OuPc3 9zCsVlWTH1XasIY0xcgqHmsHdeX46bIFSXomsFjwO2OAIaTyWgOa/uL7+qCt/59jUiM7 RehA4+W966ggztbzRSRfghUVC1DNShyk0lUMuMeTR/A0mZxNHmtejrDRNmAiyjgcxche vuWjOLEOVIg8bXblmks25bccpHjPljjK888NfiO5HiuXA/hmg91W6iw6kwDqn/cLHhFN BNcg== X-Gm-Message-State: AOAM532eXVBj9av8w2TY2s56rVrW+XUWEEqVYKFrgtrlEQRvXYvDVqSh ssk9El1AHaib1w+LMdmq0yawkLxlioX3RJpIbctBStYHEJA5ikvu56uqanNTbQFcAEvFEbH5qee EoDgl/On7NUi6QoC3218Uzw8AZNulPIy9Ozx9Xugm/BEYt5Z3BDrT3gavSOM= X-Received: by 2002:adf:a404:: with SMTP id d4mr47067029wra.156.1626937966764; Thu, 22 Jul 2021 00:12:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJws72t6GoXzqkqdYYOZQ/zPmaGiDeut0YyCtsqL2CB4Q31i/+0VkOCKcz5IUS6rDtPJVLwoVQ== X-Received: by 2002:adf:a404:: with SMTP id d4mr47066995wra.156.1626937966533; Thu, 22 Jul 2021 00:12:46 -0700 (PDT) Received: from [192.168.3.132] (p5b0c6970.dip0.t-ipconnect.de. [91.12.105.112]) by smtp.gmail.com with ESMTPSA id v15sm1930785wmj.39.2021.07.22.00.12.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jul 2021 00:12:46 -0700 (PDT) To: Evan Green , Andrew Morton Cc: 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 , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20210721143946.v3.1.I09866d90c6de14f21223a03e9e6a31f8a02ecbaf@changeid> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v3] mm: Enable suspend-only swap spaces Message-ID: Date: Thu, 22 Jul 2021 09:12:45 +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: <20210721143946.v3.1.I09866d90c6de14f21223a03e9e6a31f8a02ecbaf@changeid> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fZx+smdn; spf=none (imf05.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-Stat-Signature: ih4ixjg86yrgtxfo1fkqfe84eguwf9wg X-Rspamd-Queue-Id: DEAEF500472B X-Rspamd-Server: rspam01 X-HE-Tag: 1626937971-133222 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 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-l= evel > integrity for swap and image-level integrity for hibernate. Keeping swa= p > and hibernate separate in these cases becomes not just a matter of > preference, but correctness. >=20 > 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 t= o > it. This flag will be passed in by utilities like swapon(8), usage woul= d > probably look something like: swapon -o noswap /dev/sda2. Just a minor comment, I'd call it rather SWAP_FLAG_HIBERNATE_ONLY and=20 SWAP_FLAG_HIBERNATE_ONLY -- that calls the child by its name. I think some other flags might not apply with that new flag set, right?=20 For example, does SWAP_FLAG_DISCARD_ONCE or SWP_AREA_DISCARD still have=20 any meaning with the new flag being set? We should most probably disallow enabling any flag that doesn't make any=20 sense in combination. Apart from that, I'd love to see a comment in here why the workaround=20 suggested by Michal isn't feasible -- essentially a summary of what we=20 discussed. I had a quick glimpse and nothing jumed at me, no mm/swapfile.c expert,=20 though :) --=20 Thanks, David / dhildenb