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 DC5B614A62B for ; Mon, 11 Nov 2024 12:25:40 +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=1731327944; cv=none; b=tCV31b+s4hhfpGOZW+7XWUVXEupnVohXPgyMDnAdlp1+I62iRtnsiRo3FgKIy4tL1ZEv+ZQEe9tjofY+8wLz9EiLZYfCRSnABHhrlsdOqP1BXzkWEVQG25ftzXOI8q3t08yBVFu2sk/VmRJd4n7u1zjV/3Ro9ZeiH1ddiJyW+k0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731327944; c=relaxed/simple; bh=1oFrpUGivukzVsZON/9Fsd2HBtllmpWCGjpIFBhwDsQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NtWow48WIkHg6Zk4hG0jFsgHcdxhaseKzbTMnzF3SI6C1Q8lx+2nB6RduZ9iGH3Ld6/xEA8jv4P+QMISKzrTZZfNfnoG6ztCPWl4xSwmf3QVtK9O3uXWxIucKRpuOhBlnpOqzfE2i2nnZEWDmJf4gQN8nBUmA0d6KsR15gv9RqQ= 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 1C6421F37; Mon, 11 Nov 2024 04:26:10 -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 8D87D3F6A8; Mon, 11 Nov 2024 04:25:37 -0800 (PST) Message-ID: <046ce0ae-b4d5-4dbd-ad9d-eb8de1bba1b8@arm.com> Date: Mon, 11 Nov 2024 12:25:35 +0000 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: [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> From: Ryan Roberts In-Reply-To: <20241111131442.51738a30@mordecai.tesarici.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: > >> [...] >> I understand that Suse might be able to help with wider performance testing > > Sorry for the delay (vacation, other tasks). Anyway, let me share some > results with you. Not at all; thanks for coming back with these results! > > First, I have looked only at 4k pages (constant v. selected at boot > time) so far. > > Second, the impact of the patch series is much smaller than I expected. > Most macro-benchmarks (dbench, io-bench) did not see any significant > slowdown. There appears to be a performance hit of approx. 1-2%, but > that's within noise, and I can't dedicate my time to running extensive > tests to find the distribution peak and compare. In short, I suspect a > slight performance hit, but I cannot quantify it. > > 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. 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. Thanks, Ryan > > The dup() syscall was up to 5% slower (depends on underlying filesystem > type). > > VMA unmap was slower for some sizes, but the pattern seemed random, > sometimes giving even better performance with variable page size, so > this micro-benchmark may be too unstable to draw any conclusions. > > Stay tuned > Petr T