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 4AE08D32D8B for ; Tue, 12 Nov 2024 10:19:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C13F56B00AF; Tue, 12 Nov 2024 05:19:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BC43E6B00B1; Tue, 12 Nov 2024 05:19:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A632F6B00EE; Tue, 12 Nov 2024 05:19:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 853366B00AF for ; Tue, 12 Nov 2024 05:19:41 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3AF641416A2 for ; Tue, 12 Nov 2024 10:19:41 +0000 (UTC) X-FDA: 82777045344.22.7D1B4DB Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf04.hostedemail.com (Postfix) with ESMTP id 8BB5E40008 for ; Tue, 12 Nov 2024 10:18:46 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731406587; 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; bh=2JQNvIKvzwZQGEHrsZ3sSnuvOwvNsdWPbA2dI8+nQ2E=; b=czNGvea9zUsEFri8x6SHYqxwSLeGIEYtmQtgmRnrnXAKfdWTOAZQYNIHL/sBvNOMMrkA7+ hU51GOAttJdpKT8W/K03J/Kbf+EmZn+PkrchdcaLOdHxbXjxmFrfvCXk7C7PDPlbmzipoz 8mlTEhlWWi1D257eJ2uvASqsuJSqsD8= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731406587; a=rsa-sha256; cv=none; b=rpxU5G2ljiwhAf5h6GQgggx+gxUdoYHZWgiodahMFPhEu4fvPq8blwUFV5B7CSF4Pl4tCS Osd9RxReG/QcWY/BEsPMv75EMCk1sbs18W9ZY+mEd/tpQ5Ko7d7u74LeJo2ddLSYnIY8ES RG42vhLjSgpjgn1mBmAbXP7S2Ms4FhI= 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 5B44C25E4; Tue, 12 Nov 2024 02:20:08 -0800 (PST) Received: from [10.57.89.175] (unknown [10.57.89.175]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DA9683F66E; Tue, 12 Nov 2024 02:19:35 -0800 (PST) Message-ID: <5a041e51-a43b-4878-ab68-4757d3141889@arm.com> Date: Tue, 12 Nov 2024 10:19:34 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1 00/57] Boot-time page size selection for arm64 Content-Language: en-GB To: Petr Tesarik Cc: Andrew Morton , Anshuman Khandual , Ard Biesheuvel , Catalin Marinas , David Hildenbrand , Greg Marsden , Ivan Ivanov , Kalesh Singh , Marc Zyngier , Mark Rutland , Matthias Brugger , Miroslav Benes , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20241014105514.3206191-1-ryan.roberts@arm.com> <20241017142752.17f2c816@mordecai.tesarici.cz> <20241111131442.51738a30@mordecai.tesarici.cz> <046ce0ae-b4d5-4dbd-ad9d-eb8de1bba1b8@arm.com> <20241112104544.574dd733@mordecai.tesarici.cz> From: Ryan Roberts In-Reply-To: <20241112104544.574dd733@mordecai.tesarici.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8BB5E40008 X-Stat-Signature: xmx8dtmf8595xu56i6hhw9wkhbae9m57 X-Rspam-User: X-HE-Tag: 1731406726-585083 X-HE-Meta: U2FsdGVkX19W0WyG7OQcgne1yPa0kdL2YGCv1m8DNwyQhcIqoo8t6rhyQNYtArBVIqHP+x9t/+V6hsc7v1PKMhVDghs8HbbfyF2z207OvKF6z4DJFh6lTn7e9et9lr6wtAHodU4CaEJ368n7fUUoteu8KVDL3p6ApiGMcr8YN4nxfKr5qqo5J/hbYoEXpF2uSGwVyGy4HnYaG6uB8eBfVG4fgrhar9q8HsdsRyf3xOB2B9/0ybNpfHWDYFsqk/h7JD18Q2ebXqFGYsMYvnA0rh5As9JmjNaYJqZqA/KvdRQurmU6rROu/AvByc6bFlIJsttbyI6gyqo8poFqtwvROCuy+N99JBGvqV0Xle4Yuh7c+cQjsdOqJK22Dpv7oR/swjyMaGRNIAqqTUi6CVtExUBUmHgEaDPMThDPnD7V2WZCRBK5spe8JuOogQX5fyThBQeW4NOHD8xseg6e2rkR0IuB91ZTu9C7JQi1mgSb5pbfLt5WyOR1FSGWzt0TLRPtDLzhEIs38ShmVU7+umM9RKyKMvZnjrHHpA5XekQ+JYOpEzPdFhrZDssfHhse90lio5PWOoKFDoZ3nAUaqSV1CssEcGeJSUU5F4zdldxiPfkxR2CKd3EaUgkzurttAaKy3ZF23VFyYy2ln38AlRDzG68HvaVFLhESdmDmzwpXsuVYeD6cDJ7jegQYCe8/tRZmlOoARruIvwzfoAs75zEX8EsDPzBZcbTr2Lv7DbyjTaOK6G+dC9OXBuNcMHFbjhkOZcMEv6idaJnFzYAnvK9MD6fjJlnC/rXEdjAZFP3YM4aJFEV9z1QlE2YBvhBokE1XHrLpM4HQSZNuVbnsX/28A9RtQoz8OmZZkIYjK+rgBSm9av/mK473IPNErdY3ye6M4cu2VxHusT/O5P1Z8rzqBqR5Vz5lDJA3ETgj27kE6N4TQFIJYCNiXsbri/mRzTUQVjaeVL7gX8ePmhdiwrl 7r8uLpEa /HeihBp5c539z0aAm0dv/yPUg5bOVsIqVLgrGP0DwB3LpsjFAqmj5nNHKdLDan15EoNYGmhzYu7+eLYxa9SfBnpwb2BDT7JtKFmgr/rLqLWVivLYWj3PW6sSULFebjWVkrSZkTae7fVlLJNm5uQ1HF7mf8XeQIEd8yTHS6eYqMh1nUBP7cUf6Icw1nCAbtaLSXuxcj2aMlNpcyv4= 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 12/11/2024 09:45, Petr Tesarik wrote: > On Mon, 11 Nov 2024 12:25:35 +0000 > Ryan Roberts wrote: > >> Hi Petr, >> >> On 11/11/2024 12:14, Petr Tesarik wrote: >>> Hi Ryan, >>> >>> On Thu, 17 Oct 2024 13:32:43 +0100 >>> Ryan Roberts wrote: >> [...] >>> Third, a few micro-benchmarks saw a significant regression. >>> >>> Most notably, getenv and getenvT2 tests from libMicro were 18% and 20% >>> slower with variable page size. I don't know why, but I'm looking into >>> it. The system() library call was also about 18% slower, but that might >>> be related. >> >> OK, ouch. I think there are some things we can try to optimize the >> implementation further. But I'll wait for your analysis before digging myself. > > This turned out to be a false positive. The way this microbenchmark was > invoked did not get enough samples, so it was mostly dependent on > whether caches were hot or cold, and the timing on this specific system > with the specific sequence of bencnmarks in the suite happens to favour > my baseline kernel. > > After increasing the batch count, I'm getting pretty much the same > performance for 6.11 vanilla and patched kernels: > > prc thr usecs/call samples errors cnt/samp > getenv (baseline) 1 1 0.14975 99 0 100000 > getenv (patched) 1 1 0.14981 92 0 100000 Oh that's good news! Does this account for all 3 of the above tests (getenv, getenvT2 and system())? > >> You probably also saw the conversation with Catalin about the cost vs benefit of >> this series. Performance regressions will all need to be considered in the cost >> column, of course. So understanding the root cause and trying to reduce the >> regression as much as possible will increase chances of getting it accepted >> upstream. > > Yes. Now that the biggest number is off the table, I'm going to: > > - look into the dup() slowdown > - verify whether VMA split/merge operations are indeed slower > > Petr T