From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-189.mta1.migadu.com (out-189.mta1.migadu.com [95.215.58.189]) (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 F3DEB15E5DC for ; Fri, 23 Jan 2026 16:32:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769185961; cv=none; b=VbGnWTnrGpkZMpFNoyqNlgy9IlEia0B/MhoVQIu6I5vJig1bUBBJKqkB7Kjq/JYJJ8CbdHWSh7rRW9/qBak8j5KD8AntKN9tghPVjvydWqghvNbA0BfIDgaZeAWalqZAQc7RA+ArDlFjXrpvQDssZaUNRla0yeQdwswFPckzWhQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769185961; c=relaxed/simple; bh=0iyUTG6m2sg0RsvpN5bE4xL/EpA0AfyNWu34rWwobnM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=H0mJqZfr97622BqFBLwE/kURRZLrBwwNUcAd+tmKFbPAmR1N7rhgTBRqUT4Y7SAtiQlGF4Snyaoz5chEEi1uzeij8nzCm+tiBEyZhxVmnfEzfNW1huQFV5e4nTHpo41kmcKvZdceKS14hPRse7/n6r8y6z309AK4ncBSv97xsjU= 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=SQL3us+n; arc=none smtp.client-ip=95.215.58.189 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="SQL3us+n" Message-ID: <8fb6cba3-681a-4e63-9409-d35ab628d42c@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1769185956; 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=sPtpqluJAEzs0V3IMSuKGoLpy2/LAXVAY/2KFjo66G0=; b=SQL3us+nHv2iY77rLtpxNv3TvsI7Mw5nf88ltRAt8KtGSWnM25i8WCeC42sIrKRMAG/uyq nQjfVmb+1kCqRS3AzF7vrSF1oT6kV1dGTWDSzd+S3NdhtXvmgb00hM/kaoIXt4NuSyV2/N Erh0ASRfCAygtjnqnTmc02MPx/ZztTM= Date: Sat, 24 Jan 2026 00:32:30 +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-new v5 4/5] mm: khugepaged: skip lazy-free folios Content-Language: en-US To: Vernon Yang Cc: lorenzo.stoakes@oracle.com, ziy@nvidia.com, dev.jain@arm.com, baohua@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, david@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> 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/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. > >>> + 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; >>