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 7EBC6C07E95 for ; Wed, 7 Jul 2021 22:22:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0FEC861CD4 for ; Wed, 7 Jul 2021 22:22:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0FEC861CD4 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 8E4EC6B0011; Wed, 7 Jul 2021 18:22:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 895386B005D; Wed, 7 Jul 2021 18:22:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70E7F6B006C; Wed, 7 Jul 2021 18:22:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0038.hostedemail.com [216.40.44.38]) by kanga.kvack.org (Postfix) with ESMTP id 48B4F6B0011 for ; Wed, 7 Jul 2021 18:22:54 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7AD3D276F8 for ; Wed, 7 Jul 2021 22:22:53 +0000 (UTC) X-FDA: 78337217826.39.6F570DA Received: from mail-il1-f174.google.com (mail-il1-f174.google.com [209.85.166.174]) by imf03.hostedemail.com (Postfix) with ESMTP id C93DB300048A for ; Wed, 7 Jul 2021 22:22:52 +0000 (UTC) Received: by mail-il1-f174.google.com with SMTP id y6so3504840ilj.13 for ; Wed, 07 Jul 2021 15:22:52 -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=ANpnS5wfzyTQytr/LbOWVJj4UFY0hFcVyXu5UlKrAIM=; b=S8luKxNvVsP9qLL5333nqvhLQUZ+s2mAtAYb5+HJcG7n/eBbOwsQqHwFZBbisyIYZ5 I8GWaadMU49vq+nwhPO0XK19nFlaGjdHg5LrGMsD6VFB0XPVRrLlLxwVGhEi36YRZNEh bdgql+J7CtFci/ZJZFZeVhfkg2ydNseee4Phg= 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=ANpnS5wfzyTQytr/LbOWVJj4UFY0hFcVyXu5UlKrAIM=; b=NHVXl9REv5FZ/nULik3CKhEy16TrSpntk9Cd53H+mNNSCUmeOAIlJqn2BNhGbobX3M QOM6GqsZJSZSO91ujb6dOgWLSaSWEfZ52kFkI3Xj5O2sXW8XEfChom7Bi4vQU5yDTwz/ 1H5vQfuWWtv56Yr6FunFFSdBhsH0pM/RLzpnSf85hrtha+PBHGQV08bXj6R0+uUPfQbd kUXOeoIcCqRXV/CkkL7kM9wHgLPV/mmMV2JygSDFWQ/FU6Myighc9q7klL0V7B+6Hwc0 EYxx+Zb6LDZ1zWnXhT/XIUMZlFDkFoytdUZEXwJLZTvOmMXRbU3XhpmC88Ena+EA73Ge EtGg== X-Gm-Message-State: AOAM530TE0k5+mXJN+OLYWxVcs4YJfF0riD8+gEV6WjhEtTTX5UFUV23 qUMM9E6eB0sc38k+5ZZ0acOeaD9TDhNGBQ== X-Google-Smtp-Source: ABdhPJzMos9uS6s5OkCTWri7dmcofo4+KFdr02hBaeR4HeRkutetwY0q9qe9KfDuNI/BmfBueYODbg== X-Received: by 2002:a92:c041:: with SMTP id o1mr8888896ilf.233.1625696572016; Wed, 07 Jul 2021 15:22:52 -0700 (PDT) Received: from mail-il1-f178.google.com (mail-il1-f178.google.com. [209.85.166.178]) by smtp.gmail.com with ESMTPSA id f16sm204130ilc.53.2021.07.07.15.22.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jul 2021 15:22:50 -0700 (PDT) Received: by mail-il1-f178.google.com with SMTP id j12so4583730ils.5 for ; Wed, 07 Jul 2021 15:22:50 -0700 (PDT) X-Received: by 2002:a92:7c11:: with SMTP id x17mr18495985ilc.224.1625696570114; Wed, 07 Jul 2021 15:22:50 -0700 (PDT) MIME-Version: 1.0 References: <20210630100432.v1.1.I09866d90c6de14f21223a03e9e6a31f8a02ecbaf@changeid> In-Reply-To: From: Evan Green Date: Wed, 7 Jul 2021 15:22:14 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1] mm: Enable suspend-only swap spaces To: David Hildenbrand Cc: Andrew Morton , Alex Shi , Alistair Popple , Jens Axboe , Johannes Weiner , Joonsoo Kim , "Matthew Wilcox (Oracle)" , Miaohe Lin , Minchan Kim , Stephen Rothwell , Vlastimil Babka , LKML , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=S8luKxNv; spf=pass (imf03.hostedemail.com: domain of evgreen@chromium.org designates 209.85.166.174 as permitted sender) smtp.mailfrom=evgreen@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C93DB300048A X-Rspam-User: nil X-Stat-Signature: kmi34h6tyahe5n8dt56tk9p8tegnozh4 X-HE-Tag: 1625696572-879300 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 Mon, Jul 5, 2021 at 12:44 AM David Hildenbrand wrote: > > On 30.06.21 19:07, 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. > > Just to confirm: things like /proc/meminfo won't show this "swap that's > not actually swap" as free/total swap, correct? Maybe it's worth > spelling the expected system behavior out here. Currently these noswap regions do still count in /proc/meminfo. I suppose as you say it makes more sense for it not to count. I should be able to carefully put some conditionals around the nr_swap_pages and total_swap_pages accounting to fix that. I'll also document this in the commit text as suggested. When looking at that, I realized something else. Hibernate uses swap_free() to release its image pages, which calls free_swap_slot(). That may land the page in a swap_slots_cache, causing it to possibly leak back into general usage. I'm thinking I should just call swap_entry_free() directly if NOSWAP is set. I gave that a quick test and so far it looks good. Other random musings I had while staring that this code: It surprised me that there's swap_entry_free() and __swap_entry_free(), but the one without underscores is the lower level one (ie __swap_entry_free() winds through the cache, swap_entry_free() just does it). I'm not really sure if renaming those is worth the churn or not: leaning towards no. It's also interesting that scan_swap_map_slots() chooses whether or not to attempt reclaim based on vm_swap_full(). vm_swap_full() returns true if swap globally is 50% full or not. But hibernate is restricted to a single swap device. So you could find yourself in a situation where the hibernate device was full-but-reclaimable, and other areas aren't very full. This might cause hibernations to fail because we never attempted to reclaim swap. Maybe this never comes up in practice because people don't use multiple swap devices. Or maybe we naturally tend to spread the swap load evenly such that looking at the global counts is roughly equivalent to looking at a single one. Shower thoughts. I'll keep this in mind when I'm doing my own testing to see if it ever comes up. Thanks for the review, I'll plan to post a v2 in the next couple days. -Evan