Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261172AbTIQUVE (ORCPT ); Wed, 17 Sep 2003 16:21:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262762AbTIQUVE (ORCPT ); Wed, 17 Sep 2003 16:21:04 -0400 Received: from ns.suse.de ([195.135.220.2]:4541 "EHLO Cantor.suse.de") by vger.kernel.org with ESMTP id S261172AbTIQUVB (ORCPT ); Wed, 17 Sep 2003 16:21:01 -0400 Date: Wed, 17 Sep 2003 22:21:00 +0200 From: Andi Kleen To: Linus Torvalds Cc: Nick Piggin , Andrew Morton , Andi Kleen , linux-kernel@vger.kernel.org, richard.brunner@amd.com Subject: Re: [PATCH] Athlon/Opteron Prefetch Fix for 2.6.0test5 + numbers Message-ID: <20030917202100.GC4723@wotan.suse.de> References: <3F67E8D4.6010707@cyberone.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1746 Lines: 41 On Wed, Sep 17, 2003 at 12:53:59PM -0700, Linus Torvalds wrote: > > On Wed, 17 Sep 2003, Nick Piggin wrote: > > > > What is intriguing to me is the "Its only a 2% slowdown of the page > > fault for every cpu other than K[78] for this single workaround. There > > is no point to conditional compilation" attitude some people have. > > I wouldn't worry about performance as much as correctness. I'm a lot more > worried about the notion of taking recursive pagefaults than about 2%. I carefully designed it to never recurse more than once. The original version (before I posted it) had some corner cases that violated this, but the latest one is IMHO bulletproof in this regard. Logic is: when the fault came from user space as seen in CS it is ok to fault again. when the fault came from kernel space we must always check the exception table first. The __get_user is is_prefetch has an exception table entry and will be catched by this. [This is why I changed the SIGBUS path slightly - it previously did not follow this sequence] Also when the fault address is equal EIP we don't check. This avoids a recursion when the kernel jumps to zero. When this is not true the instruction is guaranteed to be mapped, because an unmapped instruction will always cause an page fault on EIP first. About the only chance of doing multiple recursions would be another CPU corrupting the kernel page table in parallel while the fault happens, but I don't see any chance to handle this properly. -Andi - 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/