From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (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 D2F0B1DC985 for ; Thu, 18 Jun 2026 23:03:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781823815; cv=none; b=sPqFuKpefTd8RZu+g2f5g17C+EOWN0/Kq1tUeHoASGKwivvO/S1OHXHHdVsDfFeYw3Moa1DikkSFzFs7EDBTKUlLz9djvcyaaHzbsdO7WgUr72Chnwux/8lAhXoUFuuiX5t5ys7a2OtYkJHz4onBvhNoDBBOdqRBUnFhCwuK+aQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781823815; c=relaxed/simple; bh=j93+8rTi8pygzNsPC5+MtPY3uKJqvBbzTiIyRWwITqg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=TWYlPEu1c77PyVH/aufUTtg7JwUmpOgT6phtwvWUMWR1CHQf6NkTp3R4a88PYs0YhWMCK9sxHMvOuPATWm1hUGQPYUsIM8IJkXVyQfxUN+efWv+dHLcOEaCKsaK6XOs4/mKYnRHCfkVMJWSUNN2omE+N1GqdYanu9nIbB8kNpSE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=d9ZbzunL; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="d9ZbzunL" Received: from [IPV6:2601:646:8081:7da1:99a0:e0da:db53:8fc0] ([IPv6:2601:646:8081:7da1:99a0:e0da:db53:8fc0]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 65IN369w3946263 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 18 Jun 2026 16:03:07 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 65IN369w3946263 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026052701; t=1781823788; bh=keVNytxTjta6JyUSPc5ApQkFYmG24tE2JpCBSwotXz8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=d9ZbzunLeypRIUSDD3p4C/lxAz/uJ4UyMVTOEb8dOyLDHIzMPHkHNEZ3HitS3xZny LhdhZGwLeDF9W2vyW8wIiN3A27GtN4Cap9XZdfj5VN4eRgxY6ZonAdAZxAkgO0jdKQ exicelEYkK4RxLuR4hqY3asbru0EMD+Ss+O5mNlD8tAkFldQIsfpnxHKILYSIF4s2G U5MY7wLoufgW9vOUiTilEp10iu9xUFlJWG/WpbGJpduTBJKi1CU6al2rAAFrK0PgfW uAhM/qSxKVE1lJ+Oi/unboqRJ60xfnowr+epxSZlWSptznFyN83eAT3Qvku52ZZvua bacgban8SJuWw== Message-ID: Date: Thu, 18 Jun 2026 16:03:01 -0700 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: 8aeb879baf12 - significant system call latency regression, bisected To: David Laight , Peter Zijlstra Cc: tglx@kernel.org, mingo@redhat.com, bp@alien8.de, Nathan Chancellor , Calvin Owens , Dave Hansen , torvalds@linux-foundation.org, x86-ML , LKML References: <20260613085919.GF42921@noisy.programming.kicks-ass.net> <203E61B7-290F-4F87-860F-B352D0072703@zytor.com> <20260616082814.GQ48970@noisy.programming.kicks-ass.net> <20260616145334.693c043a@pumpkin> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: <20260616145334.693c043a@pumpkin> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-06-16 06:53, David Laight wrote: > > Basically you can't win. > I was looking at why a patch didn't give the expected performance gain > on a different base kernel build. > It seems to depend on whether the function (actually strlen) was aligned > to an odd or even 16 byte boundary. > If aligned to an even boundary the loop inside the function crossed a > 'significant' boundary and the code ran measurably slower. > If you start aligning loop tops and labels in general you probably lose > due to code bloat. > (Here the loop didn't need aligning, it just needed not to contain > the relevant boundary.) > > In this case the extra padding will change the alignment of everything that > follows - and some of those might make a difference as well. > > You'd need to add extra code further down the function to keep the size > the same (and hope the compiler keeps the functions in the same order). > This is true, but this is why we want to at least be selective about it. Padding every single function generates code bloat, *and* it is a compile-time option which means that only people using a kernel built for that target will benefit. Hence this is better confined to specific ultra-hot entry point. -hpa