Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752208AbbDDGnD (ORCPT ); Sat, 4 Apr 2015 02:43:03 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:34805 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751515AbbDDGnA (ORCPT ); Sat, 4 Apr 2015 02:43:00 -0400 Date: Sat, 4 Apr 2015 08:42:55 +0200 From: Ingo Molnar To: "H. Peter Anvin" Cc: Linus Torvalds , Denys Vlasenko , Steven Rostedt , Borislav Petkov , Andy Lutomirski , Oleg Nesterov , Frederic Weisbecker , Alexei Starovoitov , Will Drewry , Kees Cook , the arch/x86 maintainers , Linux Kernel Mailing List Subject: Re: [PATCH] x86/asm/entry/64: pack interrupt dispatch table tighter Message-ID: <20150404064254.GA19587@gmail.com> References: <1428059634-11782-1-git-send-email-dvlasenk@redhat.com> <20150403140336.GA16422@gmail.com> <551EC5CD.3050901@redhat.com> <551EDD7E.3050505@zytor.com> <551EE4BE.9090507@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551EE4BE.9090507@zytor.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1486 Lines: 38 * H. Peter Anvin wrote: > On 04/03/2015 11:37 AM, Linus Torvalds wrote: > > On Fri, Apr 3, 2015 at 11:35 AM, H. Peter Anvin wrote: > >> > >> For the record, I actually measured the impact of the jump-to-jump when > >> I wrote it. It has a small, *but measurable*, positive impact. > > > > What did you compare against, and how did you measure that? I don't > > see how it could *possibly* be faster than just a simple aligned "push > > + jmp". > > > > I wish I remembered the exact details; it took a fair bit of gathering > numbers as the spread was quite a bit wider than the delta, but in the > end there were two distribution peaks clearly offset. > > I seem to remember it involving a loop running RDTSC continuously and > another RDTSC in the interrupt path. So the thing is, while I don't know how you've loaded the machine, if user-space is doing nothing but looping in RDTSC, the kernel I$ might become cache hot easily not just in L2 but in L1 cache as well. But 'when the machine is not doing anything' is not what we optimize for, we (try to) optimize for the case when there's a lot of work going on and the async context (irq, fault, etc.) I$ is likely cache-cold. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/