From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 789EE34389A for ; Tue, 9 Jun 2026 14:44:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781016271; cv=none; b=mFXf4a8JouBwlepP8zF3BdId0GU93Csl4tiNBwMQDy47lcuaed6a7EYuiY0IW02fMsVSCL+8jo5T7aJoy0gbVh1EVLLGImThE9iQNJeZduQFQq51odXgdZ1xZLgU/LepszYWdsHu7O1yMN7VS82sG9kFQQ9GHCVQY/9yVofR7XE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781016271; c=relaxed/simple; bh=h/LTuxyle4YoYh6mY0LGl6PYWDtEkH8oJY1eKe6M/oM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cIgO0AQYjzlMBgFU13TzC/zyIbWpIJBXLNS7XYG2GOLKHy6U+VCkdto4fJA4NsyAyXM7k/lfCRd0jjVp9I0GK/yNBNkwwEs0kIwWCW0OVMj29/wPSQYoWiftOvm7QlLWN3UTJK3qIjSyKzByTAvd2kLyX/n6zIxzjw7mJXFwIkQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EJKSK6tf; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EJKSK6tf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0C241F00893; Tue, 9 Jun 2026 14:44:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781016270; bh=h/LTuxyle4YoYh6mY0LGl6PYWDtEkH8oJY1eKe6M/oM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=EJKSK6tfVoJfiMgc65JDw1LIyZwhbCYFJ3Tz/3CwUMx3/5qsVcjmjKiAxzYA/3Qb4 QvQa4BIxuGn/y+ux8TJDW8wqnFVt4urkORkNhmAJlHwSGb1s5qzzX8ZlyIH98yBFRR MKvmBJgT0TdeXaF7HkAvPYUx9HKR9//s1yI96X9/4rTdJsxLuRZZLjxYp0kgk9tISF y1A9lH6yCx2M9/lCAm2cc24Ywpyr7XAnNyZZ//htrYoMku9+9uCsAhafxcYp5lGY2p J3HEhuZxvxK++83GrMDTzCCiMkAhd03bO1Of4cCFG3HwLQMOZecKuLqd5oF1Ik0svP JhWkimEXcNyiw== Date: Tue, 9 Jun 2026 15:44:21 +0100 From: Lorenzo Stoakes To: Nico Pache Cc: Luka Bai , David Hildenbrand , David Rientjes , linux-mm@kvack.org, Andrew Morton , Zi Yan , Baolin Wang , "Liam R. Howlett" , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Kairui Song , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Rik van Riel , Harry Yoo , Jann Horn , Johannes Weiner , linux-kernel@vger.kernel.org, Luka Bai Subject: Re: [PATCH 0/5] mm/khugepaged: add collapse hint machanism for khugepaged and use in mglru Message-ID: References: <20260531-thp_collapse_hint-v1-0-866339cd4c2a@tencent.com> 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: On Tue, Jun 09, 2026 at 04:17:45AM -0600, Nico Pache wrote: > I had future plans for something similar as part of the thp=auto work; > however that requires significant thought and investigation into how > we can properly gather hints for collapse/split THP candidates. From > my perspective we'd want a more global structure/system outside of > khugepaged, that would directly call khugepaged (and others like > split, etc). It would also tie into the allocator so that at fault > time it could leverage the hints to make better decisions. My fear > with this series is that making a decision now might complicate future > work by adding complexity we may eventually want to remove for a > better solution. I know this is future planning stuff, but I want to point out that we need to see significant rework of the THP code base before accepting any further major changes. > > If you have the chance perhaps you can lead a discussion on your > proposal at the biweekly MM alignment session. > > +David Rientjes as he leads those discussions. We could use that time > to layout a plan for what needs to be done for this work, and for the > work surrounding thp=auto as I beleive they will be interdependent :) We prefer to discuss THP topics in the THP cabal meeting, which both THP maintainers regularly attend :) having separate sessions we might not be aware of isn't really helpful. And 'THP auto' is a broad topic rather than a new feature. I don't think it should be seen as a topic 'owned' by anybody, but rather something that we as a community should discuss. Series that appear from nowhere trying to implement significant changes along those lines without community disucssion will not be hugely appreciated :) Thanks, Lorenzo