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 D728D25A359 for ; Wed, 11 Feb 2026 19:28:58 +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=1770838141; cv=none; b=nUiucV5SUC9Ha33fRqukMRabFzXTRVZ2Oj0QSrIIOaGj6fVR1CfhuiW/NnGrj65/SePb/iBxD3NFoFfuzzNgDVzDQncGtNyF2aLsZchjvlQ/DwI7/WFO/KqPlY3aJY1DzRwX8m5Qis0fZJ6MXpeA3eLzEoENQOeg80ABnXWSm9w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770838141; c=relaxed/simple; bh=Qw55d701xPI90OcwamyGCTQExmIM8oux9xh4xsZBPM4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=E2ibVlZmboyVO6llatqT1El3p7hDmqZOdcwJgaXbJKDlr+3UcMH6Cv5kURWhcdKvY90bDhP8adxpdDjByz2/eGHVk/SbU47XQtRFPELzsVWHA6pULv1u8wNNapBMtNy+JHn3oDi4UCDivisiV/ORQQfHEgJ0JPSEV2B0qo1sjIM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=c0BVem6M; 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=none 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="c0BVem6M" 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=yfcWTsASilNas6PFhzjcdZoCB26vcE9C04Z2aIN7kYQ=; b=c0BVem6MHbnA4jpUfZGF0UHvjx h5CycOS7eNXx9NOFHiV8l1UxnidrvOL2BNTXz5lnlqJa7KQIg9NFPipvkPm2RioO7UE+xxYk9/rqo AqYu0aAzJZ9uoJ37w4QHdpkrRaAfVzPDVM3TA0nUhK6EPWPKyHSpwnuEMReFn2FzSPnyN0dFeU1Dv jQJMTXuYMmkYpcm/YHOFUQsq1inwy96Qgg1nqyrjwXPhgCoKqIrljI3mKru4S4KS73gstDN2tzFfm n6oVzCUmzWA3YejUyBTudprHMx08PcpVcRDWV3cD6cFORCuMH9mr4Fcw7vvW683XyWB1zt/6rePwQ UtuSRMBw==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1vqFt9-0000000D5nt-28li; Wed, 11 Feb 2026 19:28:39 +0000 Date: Wed, 11 Feb 2026 19:28:39 +0000 From: Matthew Wilcox To: Usama Arif Cc: Andrew Morton , david@kernel.org, lorenzo.stoakes@oracle.com, linux-mm@kvack.org, fvdl@google.com, hannes@cmpxchg.org, riel@surriel.com, shakeel.butt@linux.dev, kas@kernel.org, baohua@kernel.org, dev.jain@arm.com, baolin.wang@linux.alibaba.com, npache@redhat.com, Liam.Howlett@oracle.com, ryan.roberts@arm.com, vbabka@suse.cz, lance.yang@linux.dev, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [RFC 1/2] mm: thp: allocate PTE page tables lazily at split time Message-ID: References: <20260211125507.4175026-1-usama.arif@linux.dev> <20260211125507.4175026-2-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: <20260211125507.4175026-2-usama.arif@linux.dev> On Wed, Feb 11, 2026 at 04:49:45AM -0800, Usama Arif wrote: > - Memory reclaim (try_to_unmap()): Returns false, folio rotated back > LRU, retried in next reclaim cycle. I was advised to ask my stupid question ... Why do we still try to split the PMD in reclaim? I understand we're about to swap the folio out and we'll need to put a swap entry in the page table so we can find it again. But can't we now store swap entries at the PMD level, or are we still forced to store 512 entries at the PTE level?