From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E6C66A55 for ; Sat, 24 Jan 2026 06:48:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769237311; cv=none; b=YVz98jACykDV+ruzH662u3068xW+xxyZbPmUEpfVYQaId9Pi3e+NG2m4aWEpbWE3X5IO22eHRcogEkcTVY3RwjmnX1bPh2o5oXLxBHqyzkIp03Ttp2Ytu5kHDtyzGlrZKR4qdEizzTVuyNp3x4DzH7l+ygt0srWHuDioxgDxVaw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769237311; c=relaxed/simple; bh=zWs8zbXrw8GSIH01CVzFBIdYbSH4XN/yTQw8G2xO4qc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Kqh4Tpq+6mNEa7OcGjXtkZdDcCkgLV+x6cGxBpNkaryFR5fBN073rxTogwyWSRNLpentJ4uqtevtaubKOjNlp+LX4Ez5LnPEHEnKOkilCcS01bd8bE7Ide4x31h+WHyA4HshqG8pEpIcS/d9Zf5tZ2pFs6ivb4hRZmvMbev1JdY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8818C1476; Fri, 23 Jan 2026 22:48:21 -0800 (PST) Received: from [10.164.10.250] (unknown [10.164.10.250]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1294C3F73F; Fri, 23 Jan 2026 22:48:24 -0800 (PST) Message-ID: <18e34ad4-82b1-42c3-b01d-ac6e5330c4e0@arm.com> Date: Sat, 24 Jan 2026 12:18:22 +0530 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-new v5 4/5] mm: khugepaged: skip lazy-free folios To: Vernon Yang , david@kernel.org, Lance Yang , baohua@kernel.org Cc: lorenzo.stoakes@oracle.com, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vernon Yang , akpm@linux-foundation.org References: <20260123082232.16413-1-vernon2gm@gmail.com> <20260123082232.16413-5-vernon2gm@gmail.com> <5820b1e9-3c45-432c-84aa-638cf92fd240@linux.dev> <8fb6cba3-681a-4e63-9409-d35ab628d42c@linux.dev> Content-Language: en-US From: Dev Jain In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 24/01/26 8:52 am, Vernon Yang wrote: > On Sat, Jan 24, 2026 at 12:32 AM Lance Yang wrote: >> On 2026/1/23 23:08, Vernon Yang wrote: >>> On Fri, Jan 23, 2026 at 5:09 PM Lance Yang wrote: >>>> On 2026/1/23 16:22, Vernon Yang wrote: >>>>> From: Vernon Yang >>>>> >> [...] >> >>>>> @@ -583,6 +584,11 @@ static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma, >>>>> folio = page_folio(page); >>>>> VM_BUG_ON_FOLIO(!folio_test_anon(folio), folio); >>>>> >>>>> + if (!pte_dirty(pteval) && folio_test_lazyfree(folio)) { >>>> I'm wondering if we need "cc->is_khugepaged &&" as well here? >>>> >>>> We should allow users to enforce collapse via the madvise_collapse() >>>> path even if pages are marked lazyfree, IMHO. >>> $ man madvise >>> MADV_COLLAPSE >>> Perform a best-effort synchronous collapse of the native pages >>> mapped by the memory range into Transparent Huge Pages (THPs). >>> >>> The semantics of MADV_COLLAPSE are best-effort and do not imply to enforce >>> collapsing, so we don't need "cc->is_khugepaged" here. >>> >>> We can imagine that if a user simultaneously uses MADV_FREE and >>> MADV_COLLAPSE, it indicates a misunderstanding of their semantics. >>> As the kernel, we need to safeguard the baseline. >> No. Afraid I don't think so. >> >> To be clear, what I meant by "enforce": >> >> Yep, MADV_COLLAPSE is best-effort - it can fail. But when users >> call MADV_COLLAPSE, they're explicitly asking for collapse. >> >> Compared to khugepaged just scanning around, that's already "enforce" >> - users are actively requesting it, not passively waiting for. >> >> Note that you're *breaking* userspace. Users would not be able >> to collapse the range where there are any lazyfree pages anymore, >> even when they explicitly call MADV_COLLAPSE. >> >> For khugepaged, skipping lazyfree makes sense. > I got your meaning, this is equivalent to two questions: > > 1. Does the semantics of best-effort imply any "enforce" meaning? > 2. When madvise(MADV_FREE| MADV_COLLAPSE), do we want to collapse > lazyfree folios? > > This is a semantic warning, and I'd like to hear others' opinions. Lance is right. When user does MADV_COLLAPSE, kernel needs to try its best to collapse. It may not be in the best interest of the user to do MADV_FREE then MADV_COLLAPSE, but that is something the user has to fix - kernel does not need to think about it. Regarding "best-effort", it is best-effort in the sense that, the madvise(MADV_COLLAPSE) is a syscall needed not for correctness, but for optimization purposes. So it is not the end of the world if the syscall fails. But, since the user has decided to do an expensive operation (syscall), kernel needs to try harder to make sure those CPU cycles weren't a waste. > >>>>> + result = SCAN_PAGE_LAZYFREE; >>>>> + goto out; >>>>> + } >>>>> + >>>>> /* See hpage_collapse_scan_pmd(). */ >>>>> if (folio_maybe_mapped_shared(folio)) { >>>>> ++shared; >>>>> @@ -1330,6 +1336,11 @@ static enum scan_result hpage_collapse_scan_pmd(struct mm_struct *mm, >>>>> } >>>>> folio = page_folio(page); >>>>> >>>>> + if (!pte_dirty(pteval) && folio_test_lazyfree(folio)) { >>>> Ditto. >>>> >>>>> + result = SCAN_PAGE_LAZYFREE; >>>>> + goto out_unmap; >>>>> + } >>>>> + >>>>> if (!folio_test_anon(folio)) { >>>>> result = SCAN_PAGE_ANON; >>>>> goto out_unmap;