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 2C3E5C7EE30 for ; Wed, 25 Jun 2025 11:03:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B32DE8D0002; Wed, 25 Jun 2025 07:03:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B0A368D0001; Wed, 25 Jun 2025 07:03:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A47268D0002; Wed, 25 Jun 2025 07:03:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 9237E8D0001 for ; Wed, 25 Jun 2025 07:03:23 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 22C5114019F for ; Wed, 25 Jun 2025 11:03:23 +0000 (UTC) X-FDA: 83593636686.15.8112F16 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by imf02.hostedemail.com (Postfix) with ESMTP id 1709E80009 for ; Wed, 25 Jun 2025 11:03:20 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=R5gPtt0Y; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750849401; a=rsa-sha256; cv=none; b=3Ul2JOje41nMFGPQKdW5PwqVmDDsWWVYlzZXz22lTMq1tM8H7U3PfPXCdG0vthKvfLrK97 pJ1wdOmwj5UGTYXb+qKrX96/T2bmZkU2Yu6owFVi0YogLt34iHRczL5oHo118YVrIlHged rM2u2UPufTLtCCnGo6BNvOufe4uiJ00= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=R5gPtt0Y; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750849401; 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=FG1P8CHryUaXZf8mi+4YebSBxRIf/UHd7sOEoQ7RTdM=; b=S8K1c3NVIDEblXCiCv415aISFtLkpd8ud2yNw3dA3y8P/oFZVtKhBSSTviotif/gT+YUsK pUk9YKpMZ8PsbRk9abroAI+2kY6SrRBjfJEOWg4Ot88ulVTTveKLj0CZMB4R7hT6+18WQa yDEztB/MdvmgZMbQNL8AiedNDL00lVw= Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-607cc1a2bd8so9687767a12.2 for ; Wed, 25 Jun 2025 04:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750849399; x=1751454199; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=FG1P8CHryUaXZf8mi+4YebSBxRIf/UHd7sOEoQ7RTdM=; b=R5gPtt0Yiz22WhDa7URlYl+YQYZEfO0fCMLSRCfLNVPnXNmWp/PiBRpPdMHYQfu27j ZjGMWZpN+/kOTzF/Hl3T2WEkWi7qaS/Kf3Zp8aqXXd4F2PTBRXINdZf5pZI4OROC9gsn Nk18Hw8cly+HBPWnrd8Q8VNgfzfl4MR69V11AQxwvcyUcBQ736gvh3X3fQym4HAnjIW+ Bx+jWvih8pn275z6cgOa06qvc+Ojd8HhpM83VjyIyPWeyjGSrgLCis+5saWXw1z5oZJB mOhfUsHnpER/y03mbzAFcRZR/H6dam/TpyY/ExIQf9VqayoADU0Sq9UYbyEsLLTsoig6 Xzkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750849399; x=1751454199; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FG1P8CHryUaXZf8mi+4YebSBxRIf/UHd7sOEoQ7RTdM=; b=Y1B+z/LFjqhKkCxPoF5K6bs/Fc8s//INGDifsalR4BKkxY7+4UDruyXIycjhi4fiK5 36Jx79tDFwj2JwB7xAPpQKjm7V3uWpWGrxgKkl15IWs7RcqASCivmmZ/5JdqJEA9Ul93 Ef+grpHSonqm1hLG2NjSD8IeexvNnuZy6+WCBVO0tEa3K9HG/tUq+9KR4qEa+6q7nIHd DLaskSVpUGda5oZ7DzccomLadQi30opjq2t/jzvWSkdCm5hvnPhjdAPkYRgWKrAKlH1I ocRxFPHI87gbRhSXpRQTVN1yRaVmCABpWhgT9Z3RrQIWpo4Hlm7BhuBZ08g7h0f2v4wA HG9Q== X-Forwarded-Encrypted: i=1; AJvYcCUbkNv70gAuWJiDEwXADkr+R5+5BatETkq5EGpW2ZXAuXYFopS3kpiPvFBOJ5pbC4vVmHmh+hTOMg==@kvack.org X-Gm-Message-State: AOJu0YwNAp7HJzlkeuMIoZZnl2Jeixmpr+aDYwqCXSSI4hcxVgTqQue3 qkKqDFZD156dKlyfw7z1sSuzQTqfsh+vI9xu+Z45IclS9mtJlT3TAq2C X-Gm-Gg: ASbGncseRxTkH+q8oTnglkLmu1Pdl9p+G7l7LGl4VhmOgUQnyydbo0i8Q5EBCqDo6iH dp64+YhZyT8RbwKZCCsgXHn+aHgrb6Roj2tf9Fhy2Ll8EOlTMCfREkKhpqWyrQ5YyjZJHyhRoH8 SH/bkOr1+kgq1LQ+eImwLNoa4a76T8O3cKMvRRUghsJfzv4oViVkEr6g7noYwRSPmNxALXcLRL9 gd/s96EKsjptaTKt8r/JozASeSLu6Z3i3lbfbelIwGt50tr3M/UZ5joGpYzgYQHT7cJ5iWZVn7j Dxq/FchknwM/qv3CCj/oDFPCbb7XwoK3t3Clj3FLuRqxGX2bGszF0xhO+0F70ON8h6omYRIcpmK pAs8SkdAcg7jEGaY2/wcUSmqiLu+XnT3L X-Google-Smtp-Source: AGHT+IGOtBi23jTRNgwJ5c1WUUVFrnDLfhHWfhKcHoNgqL6ZwQGOLzxtvPJyEH5F05dtdHi7LaEwcQ== X-Received: by 2002:a05:6402:3514:b0:5fb:e868:8730 with SMTP id 4fb4d7f45d1cf-60c4dbb9d5bmr1849558a12.10.1750849398870; Wed, 25 Jun 2025 04:03:18 -0700 (PDT) Received: from ?IPV6:2a03:83e0:1126:4:7e:645c:aa81:5180? ([2620:10d:c092:500::5:db74]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-60c2f196c6esm2320666a12.16.2025.06.25.04.03.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Jun 2025 04:03:18 -0700 (PDT) Message-ID: Date: Wed, 25 Jun 2025 12:03:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/2] fix MADV_COLLAPSE issue if THP settings are disabled To: David Hildenbrand , Lorenzo Stoakes , Hugh Dickins Cc: Baolin Wang , akpm@linux-foundation.org, ziy@nvidia.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, zokeefe@google.com, shy828301@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Johannes Weiner References: <75c02dbf-4189-958d-515e-fa80bb2187fc@google.com> <008ec97f-3b33-4b47-a112-9cef8c1d7f58@redhat.com> Content-Language: en-US From: Usama Arif In-Reply-To: <008ec97f-3b33-4b47-a112-9cef8c1d7f58@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: szb358o3z5srbfo6srbjkp3rz913y7z4 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 1709E80009 X-HE-Tag: 1750849400-396886 X-HE-Meta: U2FsdGVkX19/Wl3QkTUz6Ucrr9oqruJ24pbWW4KLLk5yhVauUjB8V3Jj9IunEOVpB8lR0bGXpDrfK1GuUn9j9r4C+yu/Wnw5WmDfWNAFYePvKBXJozs+L8wtdj3i97TkuNIV5+OQxm7KaOFb90/l6ZUYDpNatfAZpyiw/eeehbtndDqUhegU148cR8la3r/1eWd2qPx8fx7kwth3V/WWqnnLfvCJKaosI3J3mkhBA6sE8pUqLle4vOxuMgOiggFY2zCzv96fn9mBJQP1oytFE6R6784VZwTnl0EGrMrw9LyecX7FbUba0kFbzo40bEH9vmsddVaaWMljFtlxPEkluvZolSPti0bDUJcKeJiImxF4lkARX8+LSVWgFnWsY8nAxPphq0ajpaIKpXVvg/HX8Akumt8zFN33buY124D5v3+BHmupCkZ61QeFZ2RLhkJA5Qb59rVea3ldi7BdkcRC5q6phI4Wc13Q/L8Z1wCSAR/+GmhiJTIbAiUyvig56lBFu6cTaCsNM6rOyxcSNkttUQVYw5hgjmTBzg5TbK+MzlYIguYTc0AdcqqFxxjmdb/ZpATyOqloy8CMmgeRVPvvpytMsJyRXZj3iaJV1NbjO7vGYt7jq0wJNrAEyzoTgJQNMCVu8rogWFOMu8MXLYWEOHAgKHsUrxnRz4CFN6s6d0GwLxK7s16+nKmHJryHd2tT1qImP8JqBRRSFPwebn4FK1+BKSiVVwswydkKaXxQKdJzM85BxbtTRDLB+DqzlJAkGrc5g7CByHT9aQ/Xjk2+Aphtou4IVCjCAXd4wGcP3bBlbHKQqE4nnxapS/dmQjDHdM2K7KVbvT3T1hG6svLRcJsLyckSwLskzwIVdQR3KCen558YryGd7l01GSs7moVNaFftsPto+Jr3dtR5AZ0YjAi3LB+NA8DEHa93wSRqpueCL8bmDYTJ28CEtcx4yNUFBEO/8IU4zy7BzBIfhjw DZQ0w9CQ CxzQwa8pgqubQW1DD93d0QZfVG2XQsY/Dqmle/RgCJN9k1W9Rs37Kc5EUBGWPVg0+BoGgpUKMlUWJfupEBtow94+t0lTtlr1eCuZMLJu7byQUyjRUzaxZ3p/m90OKwYhKQiu/GmxufZkH9IqjQ7MsgV3ix++7HRnZc101t9VxbhWuMPfZsyxbAW7A0GsxxPesHnHGl9DSqRWgZqoHZVfS+Weus8PBND1j+G0rZffu9O+5QxnWpvFbM/PlsuuVlkI+nl4knbCTeXKBg5eByakR6f80T9BG1NtSvofjb3twpaa8TB9jcl1QqWUpmH+SiHm2HLtjC8YyoBS7W/GHelOzi5vkTLZaIpVoc1jF6dne1FlNTD4ExZwRycfg3jrxy3E2ddBGnyExXVmCxV/CIh37+xO0AZ2GCr3l1UmNC58P62AyeHuYGAb//ertaCYJBTf56VPY4vFVQuSoC2j3Bx9fWiHdwmn5kwwWyXxNqzDTNCmHPPYPPJIu+1grfDHuIPuyZj8OJuATrMVLKb4= 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 25/06/2025 08:34, David Hildenbrand wrote: >>> >>> We would all prefer a less messy world of THP tunables.  I certainly >>> find plenty to dislike there too; and wish that a less assertive name >>> than "never" had been chosen originally for the default off position. >>> >>> But please don't break the accepted and documented behaviour of >>> MADV_COLLAPSE now. >> >> Again see above, I absolutely disagree this is documented _clearly_. And >> that's the underlying issue here. >> > I feel like if you polled 100 system administrators (assuming they knew >> about THP) as to how you globally disable THP, probably all 100 would say >> you do it via: >> >> # echo never > /sys/kernel/mm/transparent_hugepage/enabled >> > > Yes. One big problem is that the documentation was not updated. > > Changing the meaning of "entirely disabled" to "entirely disabled automatically (page faults, khugepaged)" > >> So shouldn't 'never break userspace' be based on practical reality rather >> than a theorised interpretation of documents that sadly are not clear >> enough? > > I think the problem is that there might indeed be more users out there relying on "never+MADV_COLLPASE" to now place THPs than "never+MADV_COLLPASE" to no place THPs. > > What is the harm when not placing THPs? Performance degradation for some apps? > I think a bigger issue than performance degradation is someone upgrading the kernel and not seeing MADV_COLLAPSE working as it has since the beginning and not knowing that its due to a kernel change. I feel transparent_hugepage/enabled is too messed up, and its difficult to fix it without breaking it for someone? I still find it weird that we can set transparent_hugepage/enabled to never and transparent_hugepage/hugepages-2048kB/enabled to madvise and still get hugepages. (And we actually use this configuration in production for our ARM servers). Introducing deny for global and page size I feel will over complicate it because of the issue in the previous paragraph, page size setting overrides global setting. so even if transparent_hugepage/enabled is deny, we might still get a THP if the page setting is not. Someone needs to file to deny, which is the same as setting every file to never. So I just wanted to throw another bad idea in the mix, what if we introduce another sysfs file (I hate introducing sysfs :)), something like /sys/kernel/mm/thp_allowed (or some other alternate name) which is default 1. Once someone sets it to 0, no one can ever get a THP, no matter what future changes we make. Whether its madv_collapse, bpf THPs, cgroup THPs, prctls, syscalls.. never will mean never. Notice that its /sys/kernel/mm/thp_allowed and not /sys/kernel/mm/transparent_hugepage/thp_allowed. Having it one directory above will make it look uglier, but it highlights that whatever you set in /sys/kernel/mm/transparent_hugepage/ wont matter if /sys/kernel/mm/thp_allowed is set to 0. Ideally this would be /sys/kernel/mm/transparent_hugepage/enabled=never if we were developing this from scratch.. Not pushing for this idea, just throwing it out there. Thanks, Usama