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 D03FDC4338F for ; Fri, 23 Jul 2021 06:58:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6340560EE6 for ; Fri, 23 Jul 2021 06:58:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6340560EE6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 839C46B005D; Fri, 23 Jul 2021 02:58:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E9B96B006C; Fri, 23 Jul 2021 02:58:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B15B6B0070; Fri, 23 Jul 2021 02:58:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0146.hostedemail.com [216.40.44.146]) by kanga.kvack.org (Postfix) with ESMTP id 506DF6B005D for ; Fri, 23 Jul 2021 02:58:47 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E0AE4243A3 for ; Fri, 23 Jul 2021 06:58:46 +0000 (UTC) X-FDA: 78392949852.21.D1E55F5 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf13.hostedemail.com (Postfix) with ESMTP id 761BF102AFDD for ; Fri, 23 Jul 2021 06:58:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1627023525; 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=ElwTUrgx2uwYZtx6RXk2BFBNKStGzvaPr0AwpeE9zds=; b=Ar6XOjQndwGIAZJ8LffQEs39bnM1MD1rJDDVK8tyZNTlvxW/AsD67ofM5QAeOWG0SphHbt T09j+nfh+n0aFCnrm4RneULBS2g0TpXEY079QW+wEpIvW+xJaWvyA9wHiR/3HoaAlOCUWe PNKT/T259kGoveBC/axkfEwzL9p+OSA= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-481-_exslkh5NTOB5LA17HpjKA-1; Fri, 23 Jul 2021 02:58:44 -0400 X-MC-Unique: _exslkh5NTOB5LA17HpjKA-1 Received: by mail-wr1-f71.google.com with SMTP id p12-20020a5d68cc0000b02901426384855aso618786wrw.11 for ; Thu, 22 Jul 2021 23:58:43 -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=ElwTUrgx2uwYZtx6RXk2BFBNKStGzvaPr0AwpeE9zds=; b=gY3zNdhIm0SCcKDqrJTYh41YRzwTMO/dVbJF7rvbHGYILPL7xRuYpCFO9u2lPGXCsK jb4UNIskIJDezr7Q/GNHWSeBDpuJQ6JZmGsLOMkjP8dHgDy2f9dUSdV8Ybak1wGGfhf8 N99g/Fd0VV4XRU7EHXGuNcZZAy1q+InDeMhrukCgnwL74zLUEhwhPquXmFSzVFW6Dq3c LZOH6mbAi8gLZy+m+MMqikxFr+4lXNeunTxjt25S7i4oMIb1wquMFyEfBNmAINY8m2FX mrtWYPk9mKq6fjjjTRwk/GeDA/HoRy/awDNT7TVSP6CX1cvcVFhwC5F+7R1IbozTuEWy KE3w== X-Gm-Message-State: AOAM532OSKy25G9b4a0/AaO2x3kdj1/mXHx6Bm76GcOYSxf34em/qAg+ aAWI0QXRIlutFelcbIMsR5ViVBnmJjkhER9OwENHhAt6haTR/I55ULLjS1zUMvyE4Ralobt21NV HdByquM+dkTHr5ord7gO8vnsUmV84kOqd6CR2Oh60SzloSthb1mz1rv8ehqY= X-Received: by 2002:a5d:4cce:: with SMTP id c14mr3584299wrt.258.1627023522970; Thu, 22 Jul 2021 23:58:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwrQGpf3ok0FD5zzDYTaQhQ8SpdhoX7AkzghoaJR37V7X600SqkQ0mX4yh/Ddrw/dZMWcySGA== X-Received: by 2002:a5d:4cce:: with SMTP id c14mr3584258wrt.258.1627023522457; Thu, 22 Jul 2021 23:58:42 -0700 (PDT) Received: from [192.168.3.132] (p5b0c676e.dip0.t-ipconnect.de. [91.12.103.110]) by smtp.gmail.com with ESMTPSA id z13sm32834744wro.79.2021.07.22.23.58.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jul 2021 23:58:41 -0700 (PDT) To: Evan Green 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 References: <20210721143946.v3.1.I09866d90c6de14f21223a03e9e6a31f8a02ecbaf@changeid> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v3] mm: Enable suspend-only swap spaces Message-ID: <3c46df04-abf4-4bcb-b9cf-430bb1d15b07@redhat.com> Date: Fri, 23 Jul 2021 08:58:40 +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 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Ar6XOjQn; spf=none (imf13.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-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 761BF102AFDD X-Stat-Signature: mubfdd9i8rz3cx33mkb7ryyzcct9tfn7 X-HE-Tag: 1627023526-278628 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 22.07.21 20:00, Evan Green wrote: > On Thu, Jul 22, 2021 at 12:12 AM David Hildenbrand w= rote: >> >> On 21.07.21 23:40, Evan Green wrote: >>> Currently it's not possible to enable hibernation without also enabli= ng >>> 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 s= wap >>> 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 all= ow >>> 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 wo= uld >>> 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. >=20 > 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. Just imagine technology Z popping up and using also the swap=20 infrastructure. What would be the semantics of NOSWAP? With=20 HIBERNATE_ONLY it's clear -- enable that device only for hibernation,=20 nothing else. But you raise a good point: if hibernation isn't even possible in a=20 configuration (e.g., not configured into the kernel), we should simply=20 reject that flag. So if hibernation would vanish at some point=20 completely from the system, it would all be handled accordingly. That would result in quite a consistent definition of=20 SWAP_FLAG_HIBERNATE_ONLY IMHO. Makes sense? >=20 >> >> 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 hav= e >> any meaning with the new flag being set? >> >> We should most probably disallow enabling any flag that doesn't make a= ny >> sense in combination. >=20 > Good point, I can send a followup patch for that. From my reading I'd actually enjoy if we'd have that logic in the introducing patch. > 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. Might be worth fixing, indeed. >=20 >> >> 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. >=20 > 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. >=20 That would be nice to have in the patch description :) --=20 Thanks, David / dhildenb