From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outbound.ci.icloud.com (ci-2003i-snip4-11.eps.apple.com [57.103.91.221]) (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 2BAED32D0FC for ; Sun, 28 Jun 2026 16:11:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=57.103.91.221 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782663105; cv=none; b=nndm9WmdvwA0DKBIEXO7tHFcYKRlD5nUz167HA3gPfI0qxqpblCPbZx1ITyF1yr+qp5jBrvZn0oY1KdI9SW0Ziotlepfifdm4P8ySmR5wWpwO1lCgQRtbtNK5XATw/pGoCT2c83Oj57Og1uKjrLR3BsshsJyNi+9wHDaKRpD/9g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782663105; c=relaxed/simple; bh=Cma98jfyNJJ+NDh7rTXdRBnQFZGxAUrRnQqNFIayISw=; h=Message-ID:Date:MIME-Version:To:Cc:References:Subject:From: In-Reply-To:Content-Type; b=d+X9rRSnltOwoURngLqLs5+JPjPQxrIoZXoOJAxttVEBMYK0G19UX9zEaOAB7iHFslLJwlkklHeCelvSs33+iccjUzaEtJhytnzc+cLIW1byTl17npXY6WUpXwgRGc99RiaJq/iZAIKc0beGJ0xygXmYElhMyDkvbVHhc9Aj+e4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=icloud.com; spf=pass smtp.mailfrom=icloud.com; dkim=pass (2048-bit key) header.d=icloud.com header.i=@icloud.com header.b=HeyiQOSb; arc=none smtp.client-ip=57.103.91.221 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=icloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=icloud.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=icloud.com header.i=@icloud.com header.b="HeyiQOSb" Received: from outbound.ci.icloud.com (unknown [127.0.0.2]) by p00-icloudmta-asmtp-us-central-1k-100-percent-1 (Postfix) with ESMTPS id 3CE60180018E; Sun, 28 Jun 2026 16:11:41 +0000 (UTC) X-ICL-RepId: 019f0f00-3b0a-78f2-9202-d93478becd28 X-ICL-Out-Info: HUtFAUMEWwJACUgBTUQeDx5WFlZNRAJCTQhKB0MGWQReCEsLQwZcBlBcHA4XXhtCFUsVXANcDkswUBtfAkIPHBNWFRMLU1ZbE1UXRgkZCF0dGQpQUAVaEhhcFFxQWB5GElYNXQkZCFteUBtfAkIPHBNWFRMdQxkPKwhKBEMHRQJeCyUTCVNWWxNVF0YJGQhdHRkVWgkKVwdHCEkDDAQIH0haSApAAw0DQxQaBQtWRgtACkkGWFYNABEOTHMEVAddBV1WUAJaVRIEQAhWUF4IXh9MHA== Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1782663103; x=1785255103; bh=Cma98jfyNJJ+NDh7rTXdRBnQFZGxAUrRnQqNFIayISw=; h=Message-ID:Date:MIME-Version:To:Subject:From:Content-Type:x-icloud-hme; b=HeyiQOSblPh7u9R+o6RVQEas7dyHOfZ1H7b5HW5u3y+0lTcUuNuuEcqYmdC7ijndyb4ck8IKZYHK7C+QbJytQ6JMraIr2iacXjZZFfkPAewOIcFyNjSRkH/6gbPBVoJmC0S+0hDdrgjKDheAb+ysCvdwrqoVFa0onODfYX1o6XqfSrFGIuv5VaBIB6o/sYWKjyemPijuDTt7FrIJV0HcbXMZkV2yizP2kgiUb86E+4Wcb8/f7rlA0MyGTpmed9gwfaSebbGtebv5uFAlpEHJEi1aJwthKvYrcxPqyiVtw4bEgA5mMTgry9CGqAluK6MfhoMChgoeX5K1bJ9EMcHeAA== Received: from [192.168.255.10] (unknown [17.57.156.36]) by p00-icloudmta-asmtp-us-central-1k-100-percent-1 (Postfix) with ESMTPSA id C1AF818004C5; Sun, 28 Jun 2026 16:11:31 +0000 (UTC) Message-ID: <57110a3c-8c09-4f13-b6fa-903155af2a74@icloud.com> Date: Mon, 29 Jun 2026 00:11:27 +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 To: david@kernel.org Cc: akpm@linux-foundation.org, axelrasmussen@google.com, baohua@kernel.org, bruzzhang@tencent.com, hannes@cmpxchg.org, kasong@tencent.com, liam@infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ljs@kernel.org, mhocko@kernel.org, mhocko@suse.com, qi.zheng@linux.dev, rppt@kernel.org, shakeel.butt@linux.dev, surenb@google.com, vbabka@kernel.org, weixugc@google.com, yuanchu@google.com, zippermonkey@icloud.com References: <0ea1abc4-ff2c-4070-8bfa-67f6892aaca7@kernel.org> Subject: Re: [PATCH v4 5/5] mm/vmscan: flush TLB for every 31 folios evictions From: Zhang Peng In-Reply-To: <0ea1abc4-ff2c-4070-8bfa-67f6892aaca7@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-ORIG-GUID: sf7DZHFsN1vpqzlqxoeyITrRmTYWK-n8 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjI4MDE0NCBTYWx0ZWRfX2ThNs/SDP+v8 TXUHqM2ojuyyNy8n+nO5o2teq4BIvXs+0/Rmu+4K4x7MMBtYW2lo6Gdqs2ixkGT93SJmXgzn3KZ rzxLP4hfcGfyAiPn7j2MVHfXo/c+7rusf1R4Y2TxR1BN7dQLInHQvxIBhX+rQm9ll3gPQ9xV5vt GsWT168Qa1gYAmxykFNgrPDPamOrUb2ySQNoApFOHY7NRs1QeaZ3nLOJxr+8fSzfQwJPZbFOKqM bzt/A3SjS1cjktJh5d3hKQoMmIriEegykDyDpHkBUBDin3IZaVPSKiYe6x9A5HZCPqhZ0UCxWXs eIecOrlizeVVW/sazN6 X-Proofpoint-GUID: sf7DZHFsN1vpqzlqxoeyITrRmTYWK-n8 On Wed, Jun 17, 2026 at 02:47:36PM +0200, David Hildenbrand wrote: > Two tabs. But this is starting to look a bit messy. Could a helper > struct be used to reduce the parameter count to something readable? Yeah, 7 args is too many.  For v5 I'll bundle the plumbing into a small struct. > That looks rather hacky. You reinit the batch to then traverse the > batch? There must be a cleaner way. It works because reinit only zeros ->nr and ->i, the folios[] array stays intact — saved count lets you walk it while folio_batch_add() rebuilds.  But I agree it's too subtle. Maybe I will use a local temp array insteand. > Took me a second to understand why exactly you test for these > properties. Can you add a comment how these check here mimic what > we checked earlier, before dropping the lock? Will do.  The three checks correspond to what shrink_folio_list() did before the unlock: writeback may have started, swapin may have remapped the folio, a GUP may have pinned it.  Anything that fails goes back via ret_folios. > So, IIUC, what could have happened after dropping the folio lock is > that someone would have remapped the folio to user space? > > Either from the pagecache or from the swap PTE -> swapcache. > > From there, it could have gotten pinned through the page tables. > > Is that correct? Yes, exactly.  A swapin (or a page cache lookup for file-backed) can find the folio while it's unlocked, remap it into some process's page tables, and from there a GUP — O_DIRECT, vmsplice, RDMA, etc. — can pin it.  That's precisely why pageout_batch() rechecks mapped and dma_pinned before doing the TLB flush and writeout.  Any folio that got remapped or pinned in the window goes back via ret_folios instead. > What would happen if page migration finds the folio, locks it and > wants to migrate it? Migration can't find it.  The folio is off the LRU (isolated) and out of page tables (unmapped) — migration's two entry points. Compaction walks PFNs but skips !PageLRU pages.NUMA hinting faults walk page tables and won't find a folio with no PTEs.