From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 060613BBFDB for ; Thu, 23 Jul 2026 19:16:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784834204; cv=none; b=DVrpft263TBfyUxZG77I/KCisxainCNe7adMjCjVR2auUOvwhhnna14hnhtXenVNGjISIQJDMR8WfBvTQGBEE7lstGBORNxJdrlmt3beWkUFcDM90SETCcnc98n08u7N3MkVQ/XkSr3qua3mGUzlVZYjEmgv1FUOlN1LgNQdwJQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784834204; c=relaxed/simple; bh=2zu6uXoQyoVBQ/dlDmaf0bQu0kRYhdFB1d7Dj/jLEo4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nkOiPix6n01FzllpAC3+TuixvcGfLwdfAIfWmbcXsMe+KgnqqauJui06qNJhIyofFaPPy4vkc/MI6uCbDE0r9g16szcwyL7ilKBtSnPDTMO2/BVpWmAznypcdouDRc5yxyhIHPEAuz/2LhWHR4BYRuZmOoUBQpHyW94kgZyrMN8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=KmLYeQlC; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="KmLYeQlC" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=x5nDKrftDKjVFpbDlnb9u23fdFcp7Wp7gMahhMU3wz8=; b=KmLYeQlCB86DthodQOp+hSyUAG XQVw5+8fUjAzoAEhO9AafbsotRE/XtarK8FASdy4CEr++Oq6681/EYkL35WSQikQtOfwQ1HrYbiLG oywjbwATJdTk11p6uTx/mfjyaArJJHNGaXBgzqD4JjyVJCd4t3qLtnSVVLzzJSkDMxjLuAeiMeSpU aj3fzFNKuw/+BGcy0MO3OgSAVY5qooDEAGw3eaMuqPD9YuZwVzWc8IxlhZPUyUdVrFslLNy+BcwRU nc/9Cud1OdEaX6PUNJFtnTV6K57VtIWgjNwJayhnoQV/cRT1YaQwOXsz8PmaRzEMWP/KX9nq+BH+I jKj62ENA==; Received: from willy by casper.infradead.org with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1wmytv-00000001G6Q-3BIi; Thu, 23 Jul 2026 19:16:11 +0000 Date: Thu, 23 Jul 2026 20:16:11 +0100 From: Matthew Wilcox To: Usama Arif Cc: Andrew Morton , david@kernel.org, chrisl@kernel.org, kasong@tencent.com, ljs@kernel.org, ziy@nvidia.com, linux-mm@kvack.org, ying.huang@linux.alibaba.com, Baoquan He , youngjun.park@lge.com, hannes@cmpxchg.org, riel@surriel.com, shakeel.butt@linux.dev, alex@ghiti.fr, kas@kernel.org, baohua@kernel.org, dev.jain@arm.com, baolin.wang@linux.alibaba.com, Nico Pache , "Liam R. Howlett" , ryan.roberts@arm.com, Vlastimil Babka , lance.yang@linux.dev, linux-kernel@vger.kernel.org, nphamcs@gmail.com, shikemeng@huaweicloud.com, yosry@kernel.org, kernel-team@meta.com Subject: Re: [PATCH v5 10/11] mm: install PMD swap entries on swap-out Message-ID: References: <20260722152043.2273289-1-usama.arif@linux.dev> <20260722152043.2273289-11-usama.arif@linux.dev> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260722152043.2273289-11-usama.arif@linux.dev> On Wed, Jul 22, 2026 at 08:19:41AM -0700, Usama Arif wrote: > +++ b/mm/rmap.c > @@ -2282,6 +2282,25 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, > goto walk_abort; > } > > +#ifdef CONFIG_THP_SWAP > + /* > + * If the folio is in the swap cache and we're not > + * asked to split, install a PMD-level swap entry. > + */ > + if (!(flags & TTU_SPLIT_HUGE_PMD) && > + folio_test_anon(folio) && > + folio_test_swapcache(folio)) { > + if (set_pmd_swap_entry(&pvmw, folio)) > + goto walk_abort; > + > + add_mm_counter(mm, MM_ANONPAGES, > + -HPAGE_PMD_NR); > + add_mm_counter(mm, MM_SWAPENTS, > + HPAGE_PMD_NR); > + goto walk_done; > + } > +#endif > + > if (flags & TTU_SPLIT_HUGE_PMD) { > /* > * We temporarily have to drop the PTL and This makes me sad. It feels like we're bolting more complexity onto try_to_unmap() instead of removing TTU_SPLIT_HUGE_PMD entirely. Ideally we'd just cope with folios of whatever size (including PMD and PUD mapped folios) and only handle hugetlb weirdness when we absolutely have to. Similarly, we could split PUDs to PMDs and PMDs to PTEs when we need to, without the caller specifying TTU_SPLIT_anything. Is there a reason we can't do that?