From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) (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 66F002D7DC6 for ; Wed, 10 Jun 2026 02:10:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781057450; cv=none; b=Es4Hyu+f8J0uPkPELcB99P4trDAxeLg53RgcsGmGxsMtM9WCq9yGM5u2S9n1rE4R1+LE2WFiiQpHV9qMnRf+C9m4XSeZeiEGqwliQoCMwh7VG7CbiNQ20My1F4kkbBUuD89BD6kxhXLBGnhXukqC/XF9BZigdZzNz/QSp/oOE/Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781057450; c=relaxed/simple; bh=Z89CJ7D2Tl28Qt+jbLDPVVtfQFwxMKw8f5jbmYtzm6o=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=sKEITYPx/1XdN2ErwW/QRrqSiPgJpF0aY3M8Dj3cHTOsyl8/f57+f8TARmekOkb6zWeI7CJv5E+nOJVw9LDQbq6scQ0uTvq8WmotCg3W9Y6g8lolkYHgN0Oy9C6IvXYPbi7R4Hkhw5Az4ww4rW8uCbMeTopLoJQtOAqjGbav6f4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=YZc8iYLm; arc=none smtp.client-ip=91.218.175.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="YZc8iYLm" Message-ID: <0814499d-f758-49cd-ba24-6549fc5b8906@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781057446; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p1WcCUjQkrpK9ZWAZN05MiNwQO2ME50pCdKbF3ttu3U=; b=YZc8iYLmWxTVo9WJUGXSO5mWH2P032QOR4X4eXjsmDIY7cTTbPLkQiE/AWQJ7Xd3CQxrBL PqdOpyeMsgMnI+ZLEBRCAVN8YRDC95V6T1IpROCDeq98fw/5U2mLSfSBBOKcM9g4YOjHmm 7peqTREkHmtMhapijFKhY67imQ2S07k= Date: Wed, 10 Jun 2026 10:10:37 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH mm-unstable 1/1] mm/khugepaged: fix PMD collapse swap PTE accounting Content-Language: en-US To: Nico Pache , "David Hildenbrand (Arm)" Cc: akpm@linux-foundation.org, ljs@kernel.org, ziy@nvidia.com, baolin.wang@linux.alibaba.com, liam@infradead.org, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260609120443.71864-1-lance.yang@linux.dev> <7d081256-5b30-4e3c-b948-85ba76ad0e1d@kernel.org> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 2026/6/10 01:04, Nico Pache wrote: > On Tue, Jun 9, 2026 at 7:16 AM David Hildenbrand (Arm) wrote: >> >> On 6/9/26 14:04, Lance Yang wrote: >>> From: Lance Yang >>> >>> mthp_collapse() uses mthp_present_ptes to decide whether a range has >>> enough occupied PTEs to try collapse. Swap PTEs accepted by >>> collapse_scan_pmd() are counted in unmapped, but are not represented in >>> mthp_present_ptes. >>> >>> When lower orders are enabled, collapse_scan_pmd() relaxes max_ptes_none >>> so the scan can cover the whole PMD and build the bitmap. mthp_collapse() >>> then checks the PMD-order candidate using the bitmap. >>> >>> With max_ptes_none set to 0, a range with 511 present PTEs and one swap >>> PTE no longer reaches collapse_huge_page(), even though PMD collapse can >>> handle swap PTEs up to max_ptes_swap. >>> >>> Account unmapped PTEs only for PMD order. PMD collapse supports swap PTEs >>> through max_ptes_swap, while lower-order mTHP collapse does not currently >>> support non-present PTEs. Keep non-present PTEs out of the lower-order >>> eligibility check. >>> >>> Signed-off-by: Lance Yang >>> --- >>> Sent separately, as discussed in [1], to spell out the PMD-order swap PTE >>> case. Patch [2] is still only in mm-unstable, so no Fixes: tag. >>> >>> [1] https://lore.kernel.org/linux-mm/CAA1CXcD7WAiA1b9GTLAuNZ+kHaFx0SzZwpBkqAZ=s+RHsTUaow@mail.gmail.com/ >>> [2] https://lore.kernel.org/linux-mm/20260605161422.213817-12-npache@redhat.com/ >>> >>> mm/khugepaged.c | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c >>> index b12187709f6d..617bca76db49 100644 >>> --- a/mm/khugepaged.c >>> +++ b/mm/khugepaged.c >>> @@ -1508,6 +1508,14 @@ static enum scan_result mthp_collapse(struct mm_struct *mm, >>> nr_occupied_ptes = bitmap_weight_from(cc->mthp_present_ptes, offset, >>> offset + nr_ptes); >>> >>> + /* >>> + * Swap PTEs accepted during the scan are counted in @unmapped, >>> + * not in the present-PTE bitmap. Account them for the PMD-order >>> + * candidate. >>> + */ >>> + if (is_pmd_order(order)) >>> + nr_occupied_ptes += unmapped; >>> + >> >> LGTM, there is a bit of opportunity for cleanup in the future :) >> >> Acked-by: David Hildenbrand (Arm) >> >> >> For example, as we no longer have the VMA here, collapse_max_ptes_none is >> imprecise in uffd VMAs. We might try collapsing where there sure is nothing to >> collapse. >> >> We could likely handle the userfaultfd_armed() part easier: some indication that >> we must not have any pte_none() would be sufficient. >> >> Also, I don't see a good reason why uffd would not be allowed to collapse with >> zeropages ... it's really just about missing faults due to pte_none(). > > I have some patches exactly for this :) so far 2-3 patches for better > uffd handling Neat, I'll leave that to you then :) Looking forward to seeing those patches! Cheers, Lance