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 4269833D6D8 for ; Tue, 16 Jun 2026 07:12:39 +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=1781593962; cv=none; b=L63V0AXhNI23hS+qqLZyo7logmBsPoZ17BK2tcTQydDjsCTGV7XVd5FPW+f+M3IFcFx/kMPUdSIi+aKaXI2xDEOlssaQHMOuZtb6ylcaJ2f1tR6nm87szl4Ch1FxgrqvLuSnRk9MJFTXzb9KG5iMd2vQSZLChx1wnHGbeHvwOTQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781593962; c=relaxed/simple; bh=B2gUvNSCdg3G47P+6SRgQoU4v6mWCFvJ4ebse6S07eg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JYyEaHDy/9GJrVYIn5dGWctR4t6h9ni7EtrwEI+mWAwSclukgaOBN2bdL81CRDI477XXuuirJ5aJgA49V2fAGhCrVwc0zyFgFx046Q106ClrFbhhaL/1pRaSoAhM406BoKiolAmERxGVLsmdty02CaZFEdmE+NjguD/3afGqZJQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=bW7NPEwm; 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=pass 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="bW7NPEwm" 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=B2gUvNSCdg3G47P+6SRgQoU4v6mWCFvJ4ebse6S07eg=; b=bW7NPEwmQW/0CAalNRSzet6aDz 97KGEx6nDFH91b+pQw/Up6CJq9TnujzvLfwfymBXK/+leiQK295GZ5E3jehwvcYAoBItGzA3J1RoH dy0F6asNYgGpxO2YH0Hvh+DZLZOT0qKQlvk8KonepySa3PFUy0O/f5tshTOih6CTyIiiTaJzuYU5v eCx/ndF0h4TE9fJJm8NS4w8k7nv4ZrdDngygrUnsgAaC8YZ0Y89xjjdhAjpwtkIJpCyHw3s3r05GX ftHeg94BfNBONgT6//3X8OyoZ9+8+oHoEjBtgHH82tFkFMpPnHxASGGLKXn4WHeZttAAQbw7Em3s8 5YKDfQVA==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wZNyL-0000000AIeB-2UGF; Tue, 16 Jun 2026 07:12:34 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 1A2003002D8; Tue, 16 Jun 2026 09:12:32 +0200 (CEST) Date: Tue, 16 Jun 2026 09:12:32 +0200 From: Peter Zijlstra To: "H. Peter Anvin" Cc: Linus Torvalds , 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: <20260616071232.GN48970@noisy.programming.kicks-ass.net> References: <20260613085919.GF42921@noisy.programming.kicks-ass.net> <203E61B7-290F-4F87-860F-B352D0072703@zytor.com> <338ead9a-91f4-4579-9954-e18911fa3f68@zytor.com> <01ac45a8-b558-4d4d-9f8f-e7a4e725d5d2@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: On Mon, Jun 15, 2026 at 11:30:11AM -0700, H. Peter Anvin wrote: > Well, we could put it under an #ifdef by putting macro to detect when we use > -fno-jump-tables. PeterZ and I have also been talking about making > -fno-jump-tables unconditional, because at some point we found that the > performance difference was negligible, at least when array_index_nospec() is > necessary, and it makes it a lot easier to tune when you don't have to deal > with code bases that compile. It is not just retpoline but also IBT > (although the comment says "for now"); this of course means in practice that > the kernels everyone uses are compiled without jump tables. The IBT thing is because GCC (and I assume, but haven't checked, clang too) generated NOTRACK prefixes for jump tables. And we have explicitly disallowed NOTRACK for kernel IBT. The "not yet" pertains to the compilers being changed to not use NOTRACK; but I don't think this is anything anybody is actively chasing up on. So yeah, effectively jump-tables are disabled for everybody.