From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1C1381A9FA7 for ; Wed, 18 Feb 2026 04:50:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771390233; cv=none; b=PCIQ3lGDgGOJC2LDbf6ZWNLJsqW3IMojhX74GF3h02wfMjhAWURqb3dTH6fbPEtwYyGtZhpxK6sCS27KU50t4zLjGF4eo2Cl2evVpBgF6sLslTIH5i1HpSi1CPze4CF7YESd7AmIKMkJHB5+TMzsWCK5EqzE/oGFux8i7qHNWpY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771390233; c=relaxed/simple; bh=QRKLmVWmeBE1n35RnPgSettqMdTarJ3x0ofKR0Onz9c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=BttY4LGn7rteSjHwDCGXkAEFrzSGPqcjNoak8/xW5MYdPTM1h2LXEvPcoJnfSw5O9JxXKzpe3QKLIfqca3QoUwFprxSyODKNhhFnS4sHjPGRaW0e/RurvpwDzTG6YeoM5Ydah/kXGlz9LfJM7aQYWBv0l/fJZC3yBuvo4VdsEfE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 917C41477; Tue, 17 Feb 2026 20:50:22 -0800 (PST) Received: from [10.164.19.71] (unknown [10.164.19.71]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B4E3B3F7F5; Tue, 17 Feb 2026 20:50:25 -0800 (PST) Message-ID: Date: Wed, 18 Feb 2026 10:20:22 +0530 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: [REGRESSION] mm/mprotect: 2x+ slowdown for >=400KiB regions since PTE batching (cac1db8c3aad) To: Luke Yang Cc: pfalcato@suse.de, david@kernel.org, surenb@google.com, jhladky@redhat.com, akpm@linux-foundation.org, Liam.Howlett@oracle.com, willy@infradead.org, vbabka@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <764792ea-6029-41d8-b079-5297ca62505a@kernel.org> <71fbee21-f1b4-4202-a790-5076850d8d00@arm.com> Content-Language: en-US From: Dev Jain In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 17/02/26 11:13 pm, Luke Yang wrote: > On Mon, Feb 16, 2026 at 03:42:08PM +0530, Dev Jain wrote: >> On 13/02/26 10:56 pm, David Hildenbrand (Arm) wrote: >>> On 2/13/26 18:16, Suren Baghdasaryan wrote: >>>> On Fri, Feb 13, 2026 at 4:24 PM Pedro Falcato wrote: >>>>> On Fri, Feb 13, 2026 at 04:47:29PM +0100, David Hildenbrand (Arm) wrote: >>>>>> Hi! >>>>>> >>>>>> >>>>>> Micro-benchmark results are nice. But what is the real word impact? >>>>>> IOW, why >>>>>> should we care? >>>>> Well, mprotect is widely used in thread spawning, code JITting, >>>>> and even process startup. And we don't want to pay for a feature we can't >>>>> even use (on x86). >>>> I agree. When I straced Android's zygote a while ago, mprotect() came >>>> up #30 in the list of most frequently used syscalls and one of the >>>> most used mm-related syscalls due to its use during process creation. >>>> However, I don't know how often it's used on VMAs of size >=400KiB. >>> See my point? :) If this is apparently so widespread then finding a real >>> reproducer is likely not a problem. Otherwise it's just speculation. >>> >>> It would also be interesting to know whether the reproducer ran with any >>> sort of mTHP enabled or not.  >> Yes. Luke, can you experiment with the following microbenchmark: >> >> https://pastebin.com/3hNtYirT >> >> and see if there is an optimization for pte-mapped 2M folios, before and >> after the commit? >> >> (set transparent_hugepages/enabled=always, hugepages-2048Kb/enabled=always) > ---------- > amd-epyc2-rome > > # before commit > $ uname -r > 6.16.0-65.eln150.x86_64 > # after commit > $ uname -r > 6.17.0-0.rc1.17.eln150.x86_64 > > $ cat /sys/kernel/mm/transparent_hugepage/enabled > [always] madvise never > > $ cat /sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled > [always] inherit madvise never > > Before commit: Total = 6895988972 > After commit: Total = 2303697782 > Percentage change: -66.6% > > ---------- > amd-epyc3-milanx > > # before commit > $ uname -r > 6.16.0-65.eln150.x86_64 > # after commit > $ uname -r > 6.17.0-0.rc1.17.eln150.x86_64 > > $ cat /sys/kernel/mm/transparent_hugepage/enabled > [always] madvise never > > $ cat /sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled > [always] inherit madvise never > > Before commit: Total = 4006750392 > After commit: Total = 1497733191 > Percentage change: -62.6% > ---------- Thanks. So after all, batching improves stuff :) > > Luke >