From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A7C2C2264B0 for ; Wed, 17 Dec 2025 03:09:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765940977; cv=none; b=BD53HoxtD7AMg3azOPhMUCU87d++JCsz75Z394zrfsEZGR9yO3ZMtB9xdoN9RXvuqwU5cc57iyjpyANx1AL0PynnM/5BQxiI8md+Av1mSYeI6DJaHDJyk9ly3C4Ae39I/73CQq9w6Lin20PgIbWUFxgUTagT7t30vmGWDvsRhpM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765940977; c=relaxed/simple; bh=jzKV/rGlmWFZRnDiavTXwM9sL5C5JJc+7MdKxHfpqcI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lvXEHXwLFs4UQ0Wzzcu7W4HycMYIrgjG2gaKfaBl1wqcJKL94KePK5IPNrOdWRbawbV6O75Pun6Nj3zkq6Gqn6b2s/wbOATt+NJkSg2ApA1cxHFrIg9B3PqMuN9JemommUh7kfLs6rQ+Tt/gt2qv9q0lsKv+noC0Pg6Uoj0v1nc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=dyEaTMhh; arc=none smtp.client-ip=115.124.30.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="dyEaTMhh" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1765940966; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=oBMrZjjwlUZToKdAahyq4R4SSDCHf1gMyTud4G2X2/Y=; b=dyEaTMhhrloZ9Q7XipnZUMqDpN0uLCAeSkfr0zkV+MJe9rCYbaMKdJFa5dIUoGF3+tbDxIBlbUIZh7FKvm74s8t4bT3QXD4VxDHgeiMfvValsQjDBjz+Ye29QIhDWKNnf4h8KXEt40+xYk3W5W7uSh1OnJKr9EbCyH4A4bUbhYU= Received: from 30.74.144.118(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0Wv1ZBna_1765940964 cluster:ay36) by smtp.aliyun-inc.com; Wed, 17 Dec 2025 11:09:25 +0800 Message-ID: <1c6cfc9b-046e-4dec-a859-032e89e707d4@linux.alibaba.com> Date: Wed, 17 Dec 2025 11:09:24 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: Consider non-anon swap cache folios in folio_expected_ref_count() To: "David Hildenbrand (Red Hat)" , Zi Yan , Bijan Tabatabai Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, shivankg@amd.com, Hugh Dickins , Chris Li , Kairui Song References: <20251216200727.2360228-1-bijan311@gmail.com> <6b4cadb2-6246-48cc-9c76-64ba0a23198b@kernel.org> <0C218C18-916B-4BB0-8B37-AC82503E4AD9@nvidia.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2025/12/17 09:04, David Hildenbrand (Red Hat) wrote: >>>> >>>> I am not very familiar with the memory hot-(un)plug or swapping >>>> code, so >>>> I am not 100% certain if this patch actually solves the root of the >>>> problem. I believe the issue is from shmem folios, in which case I >>>> believe >>>> this patch is correct. However, I couldn't think of an easy way to >>>> confirm >>>> that the affected folios were from shmem. I guess it could be >>>> possible that >>>> the root cause could be from some bug where some anonymous pages do not >>>> return true to folio_test_anon(). I don't think that's the case, but >>>> figured the MM maintainers would have a better idea of what's going on. >> >> I am not sure about if shmem in swapcache causes the issue, since >> the above setup does not involve shmem. +Baolin and Hugh for some >> insight. > > We might just push out another unrelated shmem page to swap as we create > memory pressure in the system I think. > >> >> But David also mentioned that in __read_swap_cache_async() there is a >> chance >> that anon folio in swapcache can have anon flag not set yet. +Chris >> and Kairui >> for more analysis. > > Right, when we swapin an anon folio and did not map it into the page > table yet. Likely we can trigger something similar when we proactively > read a shmem page from swap into the swapcache. > > So it's unclear "where" a swapcache page belongs to until we move it to > its owner (anon / shmem), which is also why I cannot judge easily from > > [   49.641309] migrating pfn b12f25 failed ret:7 > [   49.641310] page: refcount:2 mapcount:0 mapping:0000000033bd8fe2 > index:0x7f404d925 pfn:0xb12f25 > [   49.641311] aops:swap_aops > [   49.641313] flags: 0x300000000030508(uptodate|active|owner_priv_1| > reclaim|swapbacked|node=0|zone=3) > [   49.641314] raw: 0300000000030508 ffffed312c4bc908 ffffed312c4bc9c8 > 0000000000000000 > [   49.641315] raw: 00000007f404d925 00000000000c823b 00000002ffffffff > 0000000000000000 > [   49.641315] page dumped because: migration failure > > What exactly that was. > > It was certainly an order-0 folio. Thanks David for the explanation. It completely makes sense to me. So feel free to add: Reviewed-by: Baolin Wang