From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754525Ab1FFQVZ (ORCPT ); Mon, 6 Jun 2011 12:21:25 -0400 Received: from r00tworld.com ([212.85.137.150]:34812 "EHLO r00tworld.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752961Ab1FFQVX (ORCPT ); Mon, 6 Jun 2011 12:21:23 -0400 From: pageexec@freemail.hu To: Ingo Molnar Date: Mon, 06 Jun 2011 18:19:36 +0200 MIME-Version: 1.0 Subject: Re: [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls Reply-to: pageexec@freemail.hu CC: Andrew Lutomirski , x86@kernel.org, Thomas Gleixner , linux-kernel@vger.kernel.org, Jesper Juhl , Borislav Petkov , Linus Torvalds , Andrew Morton , Arjan van de Ven , Jan Beulich , richard -rw- weinberger , Mikael Pettersson , Andi Kleen , Brian Gerst , Louis Rilling , Valdis.Kletnieks@vt.edu Message-ID: <4DECFE18.23229.133B32ED@pageexec.freemail.hu> In-reply-to: <20110606155953.GB7374@elte.hu> References: , <4DECF6E8.19026.131F1F1F@pageexec.freemail.hu>, <20110606155953.GB7374@elte.hu> X-mailer: Pegasus Mail for Windows (4.61) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.12 (r00tworld.com [212.85.137.150]); Mon, 06 Jun 2011 18:20:10 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6 Jun 2011 at 17:59, Ingo Molnar wrote: > > > FYI, incredible amount of work has gone into making pagefaults as > > > fast and scalable as possible. > > > > i wasn't talking about scalability (it's irrelevant anyway here), > > only speed. [...] > > Which part of "fast and scalable" did you not understand? uhm, not sure why you're so worked up here. is it because i said 'scalability' was completely irrelevant for the nx vsyscall page approach? elaborate! > Just a couple of days ago i noticed a single cycle inefficiency in > the pagefault fastpath, introduced in the 3.0 merge window. I > requested (and got) an urgent fix for that: so you must have measurements. what's the mentioned page faults take in cycles before/after your fix? what's a normal int xx path take? > So i ask you again, what is your basis for calling the #PF path on > Linux a 'slowpath'? Is Linus's and my word and 5 years of Git history > showing that it's optimized as a fastpath not enough proof for you? which part of > you must have realized by now that slow/fast path in this context were > relative to int xx vs. pf processing. did you not understand? do you have "Linus's and my word and 5 years of Git history" to show that pf processing is seriously that much faster than int xx processing?