From nobody Tue Feb 10 01:59:40 2026 Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193]) (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 CDF42341067 for ; Fri, 19 Dec 2025 19:45:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.193 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766173507; cv=none; b=kv4Il6HOVyKVUP2qRLqgwhA919orLKJLZPneyapYFgQ0+4S5tHkRvkT0Ej/KwjWV/qP5H1n54dg/OgweA2brSXGLMpIOLB/0hcj6aN9DXV2YE6HFDkHIHAHtKWQZEQaxQecYwtIWFAysCB8r7wqsFZv98N+1NFJ2DlP/aOl5UM0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766173507; c=relaxed/simple; bh=hc3YIYn1N3w0aiCvpFu7E+9gjMVbpKJVwg9n3D4XsgM=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=WVc8S+wq/+PgdBcoqmePyiKBHmbUjbqA8yudEFO2LN32t4U+9jhbvv6rLh5JnckksZJaBkoGrWfc3nwQLoiDw9RsJ3CbolbfiwtYrK1AYFbCSo7Nu/h6GDj63ujgAwQLYeZwr8FA7xaNPe5YsPXKDzBH9zzhtp+osHh9vJ4FdzQ= 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=L4hfhWln; arc=none smtp.client-ip=209.85.214.193 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="L4hfhWln" Received: by mail-pl1-f193.google.com with SMTP id d9443c01a7336-2a110548cdeso29466085ad.0 for ; Fri, 19 Dec 2025 11:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766173500; x=1766778300; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=UQJyY+YwzPf31Qkf8bV4s78sdugXZ68Qh1NEIv2FxjE=; b=L4hfhWlnkyoi8W3752RJDIRBoINzAh/kUF9ZMkTFbTaGIdLSAMXhdwAFRjp0OYGI7u eKQZ8gvAcMMI+fvLqQYGeO/54WMjPGpaH1fdL8bXa/i9ZcZCwDX7sEw5/65U+oHT969O U6upLyTWlECd3wqpkxYdexkBZ4iDbwWlSqIzYj01lBvrREZAOkkdekK+WfXTxpsfQWEZ ObS5gpOlzvRR4vOd89FeiyHdu7GbPYp4oqLOBiVMIZ+E4mEzzzrekJnTSLKTXuYWVCVD c1pe6ofxxNuMOHLN5fcGequTntnbzeIUACK/KE06U+cUpxkCYbYjet6AEfeEJJninTUi GYUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766173500; x=1766778300; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=UQJyY+YwzPf31Qkf8bV4s78sdugXZ68Qh1NEIv2FxjE=; b=Eziv6brizPmwYExRonbsRgib8YOkmwbwaAgkeE5D+H+T1QwQEVdgJQqdtthL68OtGL s2SJdFo5BBzo9gs0/E18tkAe4jUiZNTCGUv5tcOnhCbUbYwJM97URrL6R6vWTOu7+Qm0 xVZEhXVj50JT/NHTHnhjad7SX+eo2rvEOgMXp35rWRbwthe5qDw2DGcoyZJ4slTQ8x/o eina426HecLvYOIbknyHorDjkwmpe6c3cIsMoqr9ZDNecY2g9WxdsFKmD4WelY1dL/rl jEr0mIxff7CqRFJ28h7A9woDmzz3f1/S80iDQNnb/fzgcgJrkS4cCA3LTVM1CnS52okz /GpQ== X-Forwarded-Encrypted: i=1; AJvYcCXmTZWG5GpEbMrDezAuqZdkmNPQOdnObEmFZP+PDc0m7F+nyv24X+wcGkdTEZufmmTOTlQGDSp3LRZDzbs=@vger.kernel.org X-Gm-Message-State: AOJu0YxXvcWgFX2Rnxp6dEWyJlW92FGBmzDn0zXba0hkbqFXDORwumMQ yL1fY/bVUjgsLWAux91ZAXzP1AzTas8gErv2/YH8hZ/dGYEqQdYsYk93 X-Gm-Gg: AY/fxX4PtQmlzmPooyO2ddJqYwP1lRChFr/4fx3WjLW3I0SvscXnDXQ/Rh5lAoHBvjV ZdXzCnSxg90aa4/B4VgIdmrZrMjhRYRO896dZfJGdxQDJSTJmcbWIb+eDPoZmcpo3wdkaWOGbjN zGbbkGg3KkqHzU9ocmG8X2ToUutxsEAqGhuwxwM3zH/6gBl8vcK2+JR0Wk8JLZBgbsP5f4x7jHK Hvke08u4K8UApr/x+a+TNwpNh9WVw8UiIann5ulauHmGkeLsd/PDCNWuNK872e13Yh4E2VZ1AlX a/u9QEkF2i6soePeVjfOBDHBbG0/D+BBwwKti52QGyHAayTxCqjelVKStQ3ps9o8cmKgyYWN/X/ 5iG7RZI5+Y1RQHA9ciLa3BWr/CqceNwXX1rv2CQdnl29Ta4pS8W1JB2IlQ8M1/ZGL3Bnl+vZWb7 AO4C1axiW7+R1rXnQwwurPAH4DkzStmB081/lt6GCDLMl9EtkOABxe X-Google-Smtp-Source: AGHT+IH4rLRYlF7Km2RzwFxpEBaS9iEraO/JHNRLyy3vZ6hSoMKZ8Zwoy5C5IS/BflnOo3E1stDXrQ== X-Received: by 2002:a17:903:41ca:b0:295:195:23b6 with SMTP id d9443c01a7336-2a2f2a498b6mr37288195ad.55.1766173499635; Fri, 19 Dec 2025 11:44:59 -0800 (PST) Received: from [127.0.0.1] ([101.32.222.185]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a2f3d76ceesm30170985ad.91.2025.12.19.11.44.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Dec 2025 11:44:59 -0800 (PST) From: Kairui Song Date: Sat, 20 Dec 2025 03:43:38 +0800 Subject: [PATCH v5 09/19] mm, swap: swap entry of a bad slot should not be considered as swapped out 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-Transfer-Encoding: quoted-printable Message-Id: <20251220-swap-table-p2-v5-9-8862a265a033@tencent.com> References: <20251220-swap-table-p2-v5-0-8862a265a033@tencent.com> In-Reply-To: <20251220-swap-table-p2-v5-0-8862a265a033@tencent.com> To: linux-mm@kvack.org Cc: Andrew Morton , Baoquan He , Barry Song , Chris Li , Nhat Pham , Yosry Ahmed , David Hildenbrand , Johannes Weiner , Youngjun Park , Hugh Dickins , Baolin Wang , Ying Huang , Kemeng Shi , Lorenzo Stoakes , "Matthew Wilcox (Oracle)" , linux-kernel@vger.kernel.org, Kairui Song X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1766173451; l=3162; i=kasong@tencent.com; s=kasong-sign-tencent; h=from:subject:message-id; bh=Pi+TZAZwSWqdPEL23QFn7UOFD8uz8uW5toM/dBbdtuY=; b=7X9ok+JvnqWP43fxlMkDbdw05cri4rXNBYcpPfdaDU3Jd01+oq+VhQ1HNeq7aAxdnhRTb+c9w hEygOuc5yh9Dp3Ng8N4obllx+7crEibum2iJMVnJOstaDg8l3FV456u X-Developer-Key: i=kasong@tencent.com; a=ed25519; pk=kCdoBuwrYph+KrkJnrr7Sm1pwwhGDdZKcKrqiK8Y1mI= From: Kairui Song When checking if a swap entry is swapped out, we simply check if the bitwise result of the count value is larger than 0. But SWAP_MAP_BAD will also be considered as a swao count value larger than 0. SWAP_MAP_BAD being considered as a count value larger than 0 is useful for the swap allocator: they will be seen as a used slot, so the allocator will skip them. But for the swapped out check, this isn't correct. There is currently no observable issue. The swapped out check is only useful for readahead and folio swapped-out status check. For readahead, the swap cache layer will abort upon checking and updating the swap map. For the folio swapped out status check, the swap allocator will never allocate an entry of bad slots to folio, so that part is fine too. The worst that could happen now is redundant allocation/freeing of folios and waste CPU time. This also makes it easier to get rid of swap map checking and update during folio insertion in the swap cache layer. Signed-off-by: Kairui Song --- mm/swap_state.c | 2 +- mm/swapfile.c | 17 +++++++++-------- 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/mm/swap_state.c b/mm/swap_state.c index 8c429dc33ca9..b7a36c18082f 100644 --- a/mm/swap_state.c +++ b/mm/swap_state.c @@ -527,7 +527,7 @@ struct folio *swap_cache_alloc_folio(swp_entry_t entry,= gfp_t gfp_mask, if (folio) return folio; =20 - /* Skip allocation for unused swap slot for readahead path. */ + /* Skip allocation for unused and bad swap slot for readahead. */ if (!swap_entry_swapped(si, entry)) return NULL; =20 diff --git a/mm/swapfile.c b/mm/swapfile.c index e23287c06f1c..6d2ee1af0477 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -1766,10 +1766,10 @@ int __swap_count(swp_entry_t entry) return swap_count(si->swap_map[offset]); } =20 -/* - * How many references to @entry are currently swapped out? - * This does not give an exact answer when swap count is continued, - * but does include the high COUNT_CONTINUED flag to allow for that. +/** + * swap_entry_swapped - Check if the swap entry is swapped. + * @si: the swap device. + * @entry: the swap entry. */ bool swap_entry_swapped(struct swap_info_struct *si, swp_entry_t entry) { @@ -1780,7 +1780,8 @@ bool swap_entry_swapped(struct swap_info_struct *si, = swp_entry_t entry) ci =3D swap_cluster_lock(si, offset); count =3D swap_count(si->swap_map[offset]); swap_cluster_unlock(ci); - return !!count; + + return count && count !=3D SWAP_MAP_BAD; } =20 /* @@ -3677,10 +3678,10 @@ static int __swap_duplicate(swp_entry_t entry, unsi= gned char usage, int nr) count =3D si->swap_map[offset + i]; =20 /* - * swapin_readahead() doesn't check if a swap entry is valid, so the - * swap entry could be SWAP_MAP_BAD. Check here with lock held. + * For swapin out, allocator never allocates bad slots. for + * swapin, readahead is guarded by swap_entry_swapped. */ - if (unlikely(swap_count(count) =3D=3D SWAP_MAP_BAD)) { + if (WARN_ON(swap_count(count) =3D=3D SWAP_MAP_BAD)) { err =3D -ENOENT; goto unlock_out; } --=20 2.52.0