From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CA75E2F8E95 for ; Sat, 9 May 2026 16:02:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778342557; cv=none; b=lLucfmtQzng8IIFXrQBLZ19Z2OOsyshcM84t5hzL8R4XiFH71xk4Vk+X6lYG3gJNkXuhOSrmSvYlzIr0hXGXXaP6GqOn1vElVtoGORjSE/loo1CQTHTGeMwb3FYuhPE1yJBpPzG7cB5vo8+8NDuxEQBlccuAWiluKp1kOyseVGE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778342557; c=relaxed/simple; bh=jIZIvP0HPhjxEPpwjPYzgp/Z4Yg9yuzpnuHGYVcFnOU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pj3O+G5BOx2hjABPOZOWpyLFI0lMQNXbQC+ZSY/8Bgf/37dloMBQ/4sf9tydYYFWSrnYLTLXnEHB1Bz5z6zTlSolRotpDa+51/LGu1zVe0BBYRouSwAQkTQNSCOA30ti9vyzrVpy9JlYCgsl/rnAKDxeAVvGfi5xb73kmUUkuS4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=Nd0CPPQg; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="Nd0CPPQg" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=1Q6iAwhurAmWMooLpYPLKn6p5DNEYwrO+T6EQWcMDn8=; b=Nd0CPPQgOXkEWD3KHSJI9bEIFz lWnJZnxFMVHlIERv7TtkeBQXmpt7mIzQpfQDaLDaD7PJ6uJxPlm4WKVoIkK3sIYxPPCa+SLN77+Z8 o//+JpYDHHzLiOIS/8PT+BmpZvY4NhoMUxjRzBfkxW8IZFbK1KE7rr+pD4bLoPvCgkv9wVf+YKsgI E2/rb8ArjxnvaYJoV+FoMInpxHTZskxSAzyu3zUFYvZwkSGe7zlMMxBXPGBmEgozZ4duoorvm0LfV pahPUhLZ9eEe15cV0qCTCb2yWvt7zQyIz3MujrB2QRupUHAS/opJSZlAHHIMzrFRXTBdafoWAJ0TJ GsEA2kHg==; Received: from willy by casper.infradead.org with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1wLk8A-00000005iJY-0Pv8; Sat, 09 May 2026 16:02:18 +0000 Date: Sat, 9 May 2026 17:02:17 +0100 From: Matthew Wilcox To: "Liam R. Howlett" Cc: "D, Suneeth" , "Liam R. Howlett" , Andrew Morton , maple-tree@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Suren Baghdasaryan , Sidhartha Kumar , Vlastimil Babka , Alice Ryhl , Kuninori Morimoto , Geert Uytterhoeven , Arnd Bergmann , Christian Kujau , SeongJae Park Subject: Re: [PATCH v3 26/30] maple_tree: Use maple copy node for mas_wr_split() Message-ID: References: <20260130205935.2559335-1-Liam.Howlett@oracle.com> <20260130205935.2559335-27-Liam.Howlett@oracle.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, May 08, 2026 at 11:18:31PM +0200, Liam R. Howlett wrote: > On 26/05/08 02:12PM, D, Suneeth wrote: > > We run will-it-scale micro-benchmark as part of our weekly CI for Kernel > > Performance Regression testing between a stable vs rc kernel. We > > observed will-it-scale-thread-brk1 variant was regressing with > > ~9% on an AMD's Turin machine between the kernels v7.0 and > > v7.1-rc1. Bisecting further landed me onto this commit > > 280b792cac62ddadca2935766ca870b438c86323 (maple_tree: Use maple copy node > > for mas_wr_split()) as the first bad > > commit. > > Thank you for this report. > > Considering this is brk1() in thread mode, I'm going to tell you that > this test is seriously flawed and will not produce anything that looks > reasonable. The way it is written will race all over the place and thus > is unreliable. I think Liam's being too nice here. You should understand *what the test is measuring*. That's literally your job as a performance engineer. Go off and read the brk manpage. Then think about a threaded program. And under what circumstances two threads would call brk() at the same time. And what might happen if they do. "line goes up" or "line goes down" isn't necessarily uninteresting, but it's much more useful if it's set in some kind of context.