Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp5946994pxv; Wed, 7 Jul 2021 15:49:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxsIF+GRoviwVYyuOW4uxIcPDBl48Lifp0zJGZBi+4PhQdmutquZGSKNp45bhG8wI1SuhrE X-Received: by 2002:a5d:80da:: with SMTP id h26mr11982278ior.206.1625698187191; Wed, 07 Jul 2021 15:49:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625698187; cv=none; d=google.com; s=arc-20160816; b=kB0emkF6oxxQwcqPXcKFyb4pr2vC5mVdZ6OIIxl+I622FiF1Hy54z97Y5MZmr3Go79 /NRjxpUxaW4WIRbDb3tjcciYy5ReOwezZ/5jt93OCuBywfN9kb7WhvFThjemd/cBaa+y REg5kHluSw/Y0o69owdoDV3Rq3vXgAru0yn9zfIJhz7b5iwNiG0ksv1Gk1I/SbIUGcNZ FYim8sBaE3wJRukE89kIhuz9rllN0atS3e3jH4au5HjnvCCzkv7cWN2BYeCtUo+E+RnT DI2zR1O8akg/iY378XBgo22KDwhLdapVzH5aBDrr5HOzEUqdnKtUFoV1Hx/t8JF0FrU9 NWmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=ANpnS5wfzyTQytr/LbOWVJj4UFY0hFcVyXu5UlKrAIM=; b=A1Sbd9xLqtlChFg7MIO5abHhDyvwFzpCn4w2cPRY8TUokSF/Bu8K7NoH94MyMbc0Bq 8leRE5C9gtTL4bd97sV7hxbRiOVE+7lvb4iMfej+Kc2lzJvfJNUY+E7ekNxXjAH/1v9B 1KPRGAS7hKyd5XrmvAh7+cIYukpy/OkMahlC8LzLp8rPbQeKeyjYwMSQoX7ifQyznlF0 LR2U+OXNvOZ+M9b82QRAw1I0qtjQSbA4IYclZMa+nPblLJnjcMJrM1coiUbfcd5rC3aq Fo/9ukoo3xjqtuoSIvpz8NAzzaKsnzj99WPQla8aUAbxFCGRudaJp6P9TsKpbqk14AQ7 Gn7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=S8luKxNv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y10si389318ilu.132.2021.07.07.15.49.35; Wed, 07 Jul 2021 15:49:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=S8luKxNv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230146AbhGGWZe (ORCPT + 99 others); Wed, 7 Jul 2021 18:25:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229956AbhGGWZe (ORCPT ); Wed, 7 Jul 2021 18:25:34 -0400 Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6581C061574 for ; Wed, 7 Jul 2021 15:22:52 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id f12so4550993ils.11 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=M2BEkNtY2itVgqxKa1r6O4JDmoVH4w8csWwQaCxM1HhEaB12iZP6NCx6j5PSRAT3jw 78CZEkcEHgD9ZSm65VXzFwlMtDVdSRj/yPjxhEjKfPjHivnnWZ83vbVTJIt5yRSmHJxn UYM8k/QQ+hjow7QQSV7qo38s6ld5f+bILomStEJdZabRWYq+8qM69iF07C09UVsAiLmr Wht/SBYD4PG9vEWTnuXx+Ns1ygW4cmf/tT3zbhj3GGb4KjUYjqd9O037SIlVoo6gtwHR A41jkfQEa9Uu88z6UuIDxkpVlyiTJeN0LtnhKnlJt/uMUkEah4cVhPsO6DH+vhqfyE0z PSdA== X-Gm-Message-State: AOAM531thg/OtpdTLUfp2w3Ace4AmNriUTxfhq6hkFkB6mRE1FIw7NTz dmTHO+INKkFZkB9F7AajRt2u47fWnW43nw== X-Received: by 2002:a92:8e45:: with SMTP id k5mr20903518ilh.116.1625696571948; Wed, 07 Jul 2021 15:22:51 -0700 (PDT) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com. [209.85.166.176]) by smtp.gmail.com with ESMTPSA id k2sm204395ili.57.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-f176.google.com with SMTP id o10so4606873ils.6 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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