From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3190AC677C4 for ; Wed, 11 Jun 2025 07:05:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C049D6B008A; Wed, 11 Jun 2025 03:05:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB5D86B008C; Wed, 11 Jun 2025 03:05:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA6D76B0092; Wed, 11 Jun 2025 03:05:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 879F86B008A for ; Wed, 11 Jun 2025 03:05:53 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0819A1004D4 for ; Wed, 11 Jun 2025 07:05:53 +0000 (UTC) X-FDA: 83542234986.22.1F68827 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) by imf26.hostedemail.com (Postfix) with ESMTP id CD0E5140013 for ; Wed, 11 Jun 2025 07:05:49 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=fI0uVAbs; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf26.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.113 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749625551; h=from:from:sender: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:dkim-signature; bh=SYNuqTRQC6tKw1E6R0BOuzoQl4xKugq0JbOTF83k5qE=; b=6xdqhoOxAq/cLpH4qoWeydE7sV/zN4m3tcVuqBQm1Aix93HHpcwKHrm2YB3OGQN50oz7og hRfYuFuLk0EZHDwKa2DZADlNbaDt26A4HMSPkHTHgf9WouMlxP5+MDo1oVCxRGQ2M6/DvA x+DcJ7Zo/u0oOKaxblgRJR+vWpCVjPI= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=fI0uVAbs; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf26.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.113 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749625551; a=rsa-sha256; cv=none; b=ZUyR85khhfwfAHZDgQ0pRyMyXhtn05wbdJR0g4Ash5HjLlNJu61/uEi/nLSvbduVXTWCM8 swIvZlfZAhItgYQl3K8JhXlWb9r37NBzmYHMfwbJ/wIaeN2TWBQFscchZy6nMm+HONrLsa E17bqg9fw4WsBEBhQ4EovzEVZHuj8+U= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1749625542; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=SYNuqTRQC6tKw1E6R0BOuzoQl4xKugq0JbOTF83k5qE=; b=fI0uVAbs1x2OH03E4H2Wa0InRUSuzktTO6Ctu47Y/7eUT2Mqh7qkPBhsts/zuGlwOy8xTu1WHemicDelU4fHzZrBWjzKG2HLHRCPppU4+aX1pH5QUaqN7pWg1g0Alf+y5vryZIGv93f+anjO77aiPbq7IfJfkclohqmq2gmqexU= Received: from 30.74.144.128(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WdcArs0_1749625540 cluster:ay36) by smtp.aliyun-inc.com; Wed, 11 Jun 2025 15:05:41 +0800 Message-ID: Date: Wed, 11 Jun 2025 15:05:40 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/2] fix MADV_COLLAPSE issue if THP settings are disabled To: Lorenzo Stoakes Cc: akpm@linux-foundation.org, hughd@google.com, david@redhat.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <2e30bffd-bda5-4f83-b88d-c51940651a49@lucifer.local> From: Baolin Wang In-Reply-To: <2e30bffd-bda5-4f83-b88d-c51940651a49@lucifer.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: CD0E5140013 X-Stat-Signature: dt6jonde3o763tx9yryba547d1fzpzdr X-Rspam-User: X-HE-Tag: 1749625549-214252 X-HE-Meta: U2FsdGVkX19ja4hO6UPV3ZHKFQcG2zoLhYaJktUD31A5PYTNzSrU3JE/jBe8vNrrj7IxSCtZ9BPSrPV42IVm1kHtXtiOfiA4tvDpf+Es1h/y89jO5t85kNe4c/056ujnys7cKU24n9Nq+y0D+eFRu9i5xtvuEy506sNtPH4Rt6V0nYCchclTffQT42oCSwmc+rCt4ugIw4MDoqTqg/nE0zse590k+gsjh/w6/ROwNE46uWnhRlyHOyJUd5DaQ3/gSoN2ALrcrO2asTgrF6RKgu7WnpRTxNQQjW3QeKhF5FtWts2D/N0h8F2FyY3/hhBKWE833xIrWA4z7IagckhZWT3Ek0WpzAA6MJn4FausUMYmflyRZxQVFonDbcxGYQEzH8LTMTyO8S27RgMrrJh3jo8F5sk1HaObILnbT4Z/I35C0cwwEK0QdKipRY6o3haRuH4vJBJaRyUpmJbhGedW/FJLRzdBRlEmpA+8wIoS01lLP+Yk87Xx3suB/jkLVc7oPsO0tKICf9bwHOzm9r3SqSO7hhWfDtvORFfoFuYGNJ7g43X9O42NvZLMy6Iythu2Us1WproJ2OONPLy2Lb0xEgySfWHltGQ9qaBPH8Rl9UslDYGz6bvp+i1RBF96UmACgCxX7tceec74A4TZ0BI80mLAcWuz1YjkIEbQmLXd95nWkm193lvGoBggZgP4JaPamiDyLfXND7c/PhIOao+d9GWFkVKYNHgZYfbAZiVPflvR0wmgc+1w77TpdbcKHY5Wg2QUr0BAw6W3x4VBozG6KEs7tOwYYgFi7zslHneyHQBd0NA6C+nVd4WXsZ+jMFHypLsOzmuuaenoluDlWv0QuU5PvL4fX9S2dW4Nq+KQBvxdHVpiPM8Scd0hery3nw9e/O7kHo763O2CODbCC1LD4gIPp82ogkHplBN3ZD5Ur4qggr+C2Wped4+8V4o+u+FgwdjUMRixGRiAA9Mg4ZB 6IH+ZRW6 lbxHpchjsGT6qPHLK+P13Je8w7QILGJIDiCh2fr5a6k9rkHhB0ZZt2VAWgGUlWSmIMj0V+0ZK/OObXnXcD5xdYPIPK8DlX1Rkuu0eaxhGAnJX3kxcFL4Tc/IbqmT2OZLghD2cGEyxXIWeYKv3JhbGTcWDza2m/EaoXSNUHqOYid2oydZEqswHmtjVZYrXFue4Cxv6nPc4gDHPvk+d+9smUZiSzJXSq0dOJhN2td8SOhQcqy6/WRlp0Fj4Unupnct/TmO7Ei3MdtJtEMX2rmowLs/jdS2YMSYAwqX72RP/h1kUJoQRpcVc+SzZ8w700Cw4T5Tr7WcQPOCImK2b0CPoeg5V8us8VHcXqlt18ZVZuseTJPeQMxAYHaB6oA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2025/6/7 20:28, Lorenzo Stoakes wrote: > Before I get into technical criticism, to be clear - thank you very much > for doing this :) I'm just getting into details as to the implementation, > but am a fan of this change and consider it important. > > On Thu, Jun 05, 2025 at 04:00:57PM +0800, Baolin Wang wrote: >> As we discussed in the previous thread [1], the MADV_COLLAPSE will ignore >> the system-wide anon/shmem THP sysfs settings, which means that even though >> we have disabled the anon/shmem THP configuration, MADV_COLLAPSE will still >> attempt to collapse into a anon/shmem THP. This violates the rule we have >> agreed upon: never means never. This patch set will address this issue. > > Hm this cover letter could be expanded upon quite a bit - you are doing a > lot here and it's not only MADV_COLLAPSE, more a general change. > > I'd mention that, even when TVA_ENFORCE_SYSFS is not set, callers checking > THP order validity will not be able to specify THP orders that are either > specifically marked as 'never' or set to 'inherit' and the global hugepage > mode is 'never'. > > Then say something like 'importantly, this changes alters the madvise(..., > MADV_COLLAPSE) call, which previously would collapse ranges into huge pages > even if THP was set to never. This corrects this behaviour'. > > I suspect you are unable to write sensible tests here given the need to > manipulate sysfs (though perhaps worth quickly looking at > tools/testing/selftests/mm/khugepaged.c, transhuge-stress.c, run_vmtests.sh > to see), but it'd be at least useful for you to give details here of how > you have tested this and ensured it functions correctly. > > It might also be worth giving a quick justification, i.e. 'system > administrators who disabled THP everywhere must indeed very much not want > THP to be used for whatever reason - having individual programs being able > to quietly override this is very surprising and likely to cause headaches > for those who desire this not to happen on their systems'. > Ah, missed this comment. Good suggestion, I will update the cover letter. Thanks.