From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) (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 3053A40DB2F for ; Mon, 14 Sep 2026 08:32:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.101 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789374780; cv=none; b=MXGgpgR0C5xiLyHU5vx8RXE1txfrtRhBRHL1p2fhI+tgKzC0yVg8bzmk6b7nN7vsZqLmY6r8l8yfFUo31L/32RODnGqrFVw5hy/k7QHQoYv/DrGFwpd6Sq3ZzLM5ypMh9d/ezP51oijndAa6oS1WUPxqteWK88y4ZR3E4YTU8T8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789374780; c=relaxed/simple; bh=gaWfHviegHfFx748PRo21TXEPqh35ErtH3vWXYt7Ngk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QDJH7e5+emCvO3DpkR8uTbtip2EKxODe7x9MO8rpVxzgt//UQYmzpookLHzMvHRWZeYYtVkSPn0iIeifRwZxkveFfpq5yi4ztH3kkvJFdKoXSDbAnBi4RgvObiyY0ezbheJ1G/5wKbB8sXJ098YDxJBEmMqUj0cEX5kdJcJWmu0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=bPjfrvER; arc=none smtp.client-ip=115.124.30.101 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="bPjfrvER" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1789374770; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=V5SgxrpCr+3rPiETqStc1WoDgDVOaLwcyekKiy2XRu0=; b=bPjfrvERnS787nd6X/u8wHOITjBrc0aGeVj97hF/K7CpXeSeZzjfZHAApjXrP4riqZVmYVkJvOpq6SJwrahXqwU0UIQpU27YTGm/PdahfzkeBamwo7QYuwUrwWDNPDKXEZ1UNnYc1xO4jlxCnhH+53g6zX4AXsszdbpa8EWipeU= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R161e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037033178;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=18;SR=0;TI=SMTPD_---0XAtYEDx_1789374767; Received: from 30.74.144.134(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0XAtYEDx_1789374767 cluster:ay36) by smtp.aliyun-inc.com; Mon, 14 Sep 2026 16:32:48 +0800 Message-ID: Date: Mon, 14 Sep 2026 16:32:46 +0800 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 v2 05/12] mm/collapse: state what a collapse may do in the policy To: Kiryl Shutsemau , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , Zi Yan Cc: "Kiryl Shutsemau (Meta)" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Vlastimil Babka , Jann Horn References: <20260910120238.2529819-1-kirill@shutemov.name> <20260910120238.2529819-6-kirill@shutemov.name> From: Baolin Wang In-Reply-To: <20260910120238.2529819-6-kirill@shutemov.name> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/10/26 8:02 PM, Kiryl Shutsemau wrote: > From: "Kiryl Shutsemau (Meta)" > > Tests scattered through the collapse path decide what a collapse is > allowed to do by asking whether khugepaged started it. Between them they > settle: > > - which VMAs are eligible, and how hard to try for a folio; > - how many empty, swapped-out or shared PTEs a window may contain, and > whether a sub-PMD window is held to a stricter rule than a PMD; > - whether a range has to look used, and whether a MADV_FREE'd page is > left alone; > - whether the PMD is mapped as part of the request, and whether dirty > pages are worth writing back and retrying. > > None of those is a fact about khugepaged. Each is something the caller > decided before asking, and the collapse code should not have to look up > who called to find out. > > Add struct collapse_policy for the caller to fill: khugepaged from its > own settings, MADV_COLLAPSE from the fact that a user asked explicitly. > Every test becomes a read of a field, and cc->is_khugepaged goes, having > no reader left. > > khugepaged fills the policy once per scan pass, MADV_COLLAPSE once per > call. That is the one change in behaviour. The max_ptes_* limits and the > defrag setting behind the allocation mask are sampled once per pass rather > than on every table. A table scanned early in a pass and one scanned late > are then judged alike. > > collapse_file() also drops a NULL check on the collapse_control. It has > one call site, reached only from collapse_single_pmd(), which dereferences > cc unconditionally, so the check was already dead. > > Assisted-by: LLM > Signed-off-by: Kiryl Shutsemau (Meta) > --- Thanks. The logic is much clearer now. Reviewed-by: Baolin Wang