From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F4E326ED54 for ; Mon, 16 Feb 2026 06:21:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771222880; cv=none; b=NqoEF79WRpNJJ5a8atIEuZs6imAPZKSLmbqQh4MH+6neV2nQ1kK4zE9m60wIL0DQbXDjbtO4eieo9C/I0dBqJYY0IHANIzNOUSzuI5bMWIG3hkd7lZdPncRDqTtaN1i+p0NEYs32RDQ2ZD20vPvbzWwaj06r10oR1bQ4Wb0svLQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771222880; c=relaxed/simple; bh=HRlJ5n1R99XLcAS+BQ9ghV0hCDdA4JHEulnwQB5H2wQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Tkstjg51afCECNcffWWtRZ1i/gYO9EvfiiqizC98WLhSuYNZcwq2PWhPDq1rYzYui2OIRNfZ2A3PLjZKqPaHrdFRNrbEJ67JcaPKTCXfj6LGB+LcYm+kSasNksZv/mUC5v053Fgkjavl1HpyaKvteO69lX2IwOABLUJgv3uutF8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jcdkee6G; arc=none smtp.client-ip=209.85.214.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jcdkee6G" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-2aaf59c4f7cso12772945ad.1 for ; Sun, 15 Feb 2026 22:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771222878; x=1771827678; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=+B3VYFqqOtn4OFDnrRnwc7y2rxPOL/UksRHhaZ3LZ4U=; b=jcdkee6Gw95GOSgcrOnPgrM1wWQo4ZVKU3n/ay986yl9NeLKNNCMCbcscatcuYA1S3 PG8sKLW2DnlRQByyx+t7X2f/twCmJXY9qmHxfG84rCJmE8n3Ip9mT/e02qVYkGhVU3t3 GTZJILdrGWVf0US5zH5kaYLsJchTn2LxhMYgpx00AY+kZ+oN3tYD3bur+u2e02R8qf7S tjC3Tz7dXDE6GVhZGqABMm8QBmmyimEphHy8nX+YIbqGQ1Am27ZtWpdux2nahOJbdtbb KTamr1AUirTh/7Xt686sHxA45/wFDcTls29bBzBxkMt7GH3R3Ypp8C2Qq263Q9BMaFgB VvQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771222878; x=1771827678; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+B3VYFqqOtn4OFDnrRnwc7y2rxPOL/UksRHhaZ3LZ4U=; b=A9lPpwY4JLz/jQSP2s3L2ALAIcYb7r0toQoLuzZlMZ0f+tcWsd0rke6TjWLizOPqox LI/Uo5UK65KCWX86Eru/1sUX1fqJGBilJpsL93+FxrgJ9OGD5A2sLDKeBw39WZix1Rmo BMvfUEDhZZzN5MJT2inrePn/vgxyZWyXG6pcYEamKZDqMBCJt5abgD/OJHKRg06AD+fY VUFfTosMmxAIpnpok6YyDpbdEWt85Kubak4N+N3Kv+MedcISMzh/9G22ZPR8v+YsieXN ZMhyy5kjTmNfsPS5mJWi4cksBTGiVGqLdq4EIBByOYltN7TCYJRd8J7spXyO0Zv9sf6C UnxA== X-Forwarded-Encrypted: i=1; AJvYcCU5rWNENPWb9yGqHq+U+mxZTuqWZs5uX5t5XnDfDMYRx+QYM7Jn8s1jD3UPy/mvN5Y0/t4rUI4MaJn8hEo=@vger.kernel.org X-Gm-Message-State: AOJu0YxzGCxwdWnrJJCnIXwhYuQKrWdaY95T3hFUGJi4xjgWEAfv6WDg Pm/8wEN6fRK5Jpe+7FxSA+iwOJ2HiHVri+lqW9LJir5dbiIT8AbVRmRG X-Gm-Gg: AZuq6aIvRVzaECY2sbUYut73r27kyBBGhsXWQfLDDOuuBY9PnYaLJ89jw5SXkMqX6SX Ad9dUAcG9eIVk6mjlbx1cSJFz+ehhhOHK629YUIO/YVtXmAodcasXXZ0/21c60JY8J1+F7xL3RM GxmvN2bnlA77ONuK7wMmOM6y5IpvP3pdarWDAH3+rxxxF9e/fU3lpXZO2BkFGwfeHCVtTItKpX7 /SfQbTGMOHVkbkRh7rkUe90NRFBg8LqLB+bWjUzOHOaw2k8nkkpQ82RqlPopUPU2P/XMqDhREX7 el6K4Z2e4+6KTijHfBNB40UhAPKtnaE+HsyFMqbZITKcXFRzbzMyJzky2esqVQ4pftxflGpkFtf YEZRuR+jpRxKj58izr7Vj6baA3uxGBv4FpqcS2rgFywDenao7acKuqVoaqffh+ewvPao0oiAyHs qcn8lLtpS4A5jFJe/jr1jjxC/zLJ8tOEt5TzWpPoZqEmIQX3tiW0/z/7w0g84= X-Received: by 2002:a17:903:298d:b0:296:2aed:4fab with SMTP id d9443c01a7336-2ab50519c2dmr97137435ad.23.1771222878384; Sun, 15 Feb 2026 22:21:18 -0800 (PST) Received: from KASONG-MC4 ([101.32.222.185]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ad1a9d5bbcsm60375565ad.56.2026.02.15.22.21.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Feb 2026 22:21:17 -0800 (PST) Date: Mon, 16 Feb 2026 14:21:12 +0800 From: Kairui Song To: Barry Song <21cnbao@gmail.com> Cc: kasong@tencent.com, linux-mm@kvack.org, Andrew Morton , Chris Li , Kemeng Shi , Nhat Pham , Baoquan He , Carsten Grohmann , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, "open list:SUSPEND TO RAM" , Carsten Grohmann Subject: Re: [PATCH v3 2/3] mm, swap: reduce indention for hibernate allocation helper Message-ID: References: <20260216-hibernate-perf-v3-0-74e025091145@tencent.com> <20260216-hibernate-perf-v3-2-74e025091145@tencent.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Feb 16, 2026 at 07:20:49AM +0800, Barry Song wrote: > On Mon, Feb 16, 2026 at 3:00 AM Kairui Song via B4 Relay > wrote: > > > > From: Kairui Song > > > > It doesn't have to check the device flag, as the allocator will also > > check the device flag and refuse to allocate if the device is not > > writable. This might cause a trivial waste of CPU cycles of hibernate > > allocation raced with swapoff, but that is very unlikely to happen. > > Removing the check on the common path should be more helpful. > > > > Signed-off-by: Kairui Song > > --- > > mm/swapfile.c | 38 ++++++++++++++++++-------------------- > > 1 file changed, 18 insertions(+), 20 deletions(-) > > > > diff --git a/mm/swapfile.c b/mm/swapfile.c > > index 32e0e7545ab8..0d1b17c99221 100644 > > --- a/mm/swapfile.c > > +++ b/mm/swapfile.c > > @@ -1936,27 +1936,25 @@ swp_entry_t swap_alloc_hibernation_slot(int type) > > > > /* This is called for allocating swap entry, not cache */ > > if (get_swap_device_info(si)) { > > > I guess we could further reduce indentation by doing: > if (!get_swap_device_info(si)) > goto fail; > Agree, I think we can make it even simpler by having: /* Return empty entry if device is not usable (swapoff or full) */ if (!si || !get_swap_device_info(si)) return entry; Then the `fail` label is also gone. I'll post a v4 later today combined with your another suggestion. Thanks!