From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 C050C3D34A0 for ; Wed, 17 Jun 2026 10:05:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781690711; cv=none; b=X2FhgR7OSV3sE2WffBkn6vH7Agl5VWIy7w7neI55On7mofMPIxDE2V6KcD68Usa/RSe74HgEwFQXGqJPRXUa84Wxw4hMaihppUB58v39pkcPRsbkFkexPnJ82HTuL8h2p3pFtcmCkY/sqmqYaGOSaT60wyHY3v+oXBJ4BlTO9tY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781690711; c=relaxed/simple; bh=WIho6H12SWfzGdVkfEuWbQvjfUOUT3nDeTBbaad29dA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Qc24Tlu5SuKh7Q+pXtHcydpwEIAAKOt9cU8GrNsZMKe9A9pvOyChqzevcMZDKIL6+r1BUIYC+9ktWIAbDne+k4k7GXuI6Yk5vuZzKCdTKqSWBIYG7iICNvORBnfygEk7IpSS4UZ6k6Uu6JZllDlzJmZUMusoezQtxZ7gT8BqvXY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VjSCVqOX; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VjSCVqOX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 728681F00A3A; Wed, 17 Jun 2026 10:05:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781690709; bh=gz3/BXihjMp5zGllwBexnGt5zqRGA69V/DbfyAcWiwQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=VjSCVqOXIyMho76c2+YxoksqfBF8dnkixbphJBhJBJY7hbMfKEOK+8WWxMfXvFs9c tdmf6Xvt58H8WLMIFYEha+SMHH0786m1vnhohvuYeOq8bv81o8C7k8zCiDvqb8P9py q7nzPKRwVjb6AixdHLpLZtVm4Ydv5Z9TBSzVdWIl2t/TiGMACkKFHrqXPQbXBwoKTu Hxv5Ubh9tyoQs1zcdQL5pQUCLio1tsgfZto5+DH6YrBR0hfqNa19fjuKEiRWv+uENt 8X+THTUvPHD9R0lQGxT7HJpem3RVRfTPh83F+kPOy0/BbY0yJ31fSoMi6Hkk8uJqjB at9E9Pw4vDOjQ== Date: Wed, 17 Jun 2026 12:05:04 +0200 From: Ingo Molnar To: "H. Peter Anvin" Cc: Linus Torvalds , Peter Zijlstra , tglx@kernel.org, mingo@redhat.com, bp@alien8.de, Nathan Chancellor , Calvin Owens , Dave Hansen , x86-ML , LKML Subject: Re: 8aeb879baf12 - significant system call latency regression, bisected Message-ID: References: <20260613085919.GF42921@noisy.programming.kicks-ass.net> <203E61B7-290F-4F87-860F-B352D0072703@zytor.com> <20260616082814.GQ48970@noisy.programming.kicks-ass.net> <9D5BDF61-3C14-4F21-9D8C-4AB7F28B7EEC@zytor.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: * Ingo Molnar wrote: > I'd exclude the L0D, L1DTLB, the RSB and the load/store queues > as well, because code alignment of a single symbol should have > a minimal effect on them, which leaves: > > - uOP Queue - 192 entries > - uOP Cache (Micro-op Cache) - ~5,250 uOPs, ~64 sets x 10-12 way > - Reorder Buffer (ROB) - 576 entries > > And I think of these the main suspect would be the uOP cache, > because its (estimated...) ~10-12 deep associativity limit > of uop-sets may be something this benchmark is hitting on > Panther Lake? > > Could it be that the extra alignment adds +1 to the maximum number > of uOP cache 'ways' this execution hits in the uOP cache, moving > it form say 12 (still fits) to 13 (misses) so that this particular > uOP cache association depth starts trashing? But I'm really just > guessing wildly here... > > ( The extra statistical noise of the regressed figures does suggest > some sort of trashing mechanic behind the scenes though, and the > regular caches seem large enough to not actually trash for such > a cache-hot benchmark. ) > > Or am I missing something obvious? > > Any perf stat uOP related counter measurements might be illuminating. The relevant uOP cache (Intel DSB) perf stat counters would be: starship:~/tip> git grep DSB_ tools/perf/pmu-events/arch/x86/pantherlake/ tools/perf/pmu-events/arch/x86/pantherlake/frontend.json: "EventName": "FRONTEND_RETIRED.ANY_DSB_MISS", tools/perf/pmu-events/arch/x86/pantherlake/frontend.json: "EventName": "FRONTEND_RETIRED.DSB_MISS", tools/perf/pmu-events/arch/x86/pantherlake/frontend.json: "EventName": "IDQ.DSB_CYCLES_ANY", tools/perf/pmu-events/arch/x86/pantherlake/frontend.json: "EventName": "IDQ.DSB_CYCLES_OK", tools/perf/pmu-events/arch/x86/pantherlake/frontend.json: "EventName": "IDQ.DSB_UOPS", In particular FRONTEND_RETIRED.ANY_DSB_MISS and FRONTEND_RETIRED.DSB_MISS before/after counts? Thanks, Ingo