Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965467Ab0GPMzH (ORCPT ); Fri, 16 Jul 2010 08:55:07 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.124]:63437 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965280Ab0GPMzF (ORCPT ); Fri, 16 Jul 2010 08:55:05 -0400 X-Authority-Analysis: v=1.1 cv=Wd4F0Mu8V05kqqt67pyjJbbzQCzSsR+BbLtAgo88TiY= c=1 sm=0 a=ZI5MULQygNwA:10 a=ood2b7iyd8MA:10 a=IkcTkHD0fZMA:10 a=gMqfjgEr1zLu/65IO0LwxA==:17 a=C8wtieY37JN1cNuiyTUA:9 a=Kz5WqQLA3YsJU56H078A:7 a=QoIsEb3dWOhRzQwELjc2B6VCgI0A:4 a=QEXdDO2ut3YA:10 a=gMqfjgEr1zLu/65IO0LwxA==:117 X-Cloudmark-Score: 0 X-Originating-IP: 74.67.89.75 Subject: Re: [patch 1/2] x86_64 page fault NMI-safe From: Steven Rostedt To: Frederic Weisbecker Cc: Linus Torvalds , Mathieu Desnoyers , Andi Kleen , Ingo Molnar , LKML , Andrew Morton , Peter Zijlstra , Steven Rostedt , Thomas Gleixner , Christoph Hellwig , Li Zefan , Lai Jiangshan , Johannes Berg , Masami Hiramatsu , Arnaldo Carvalho de Melo , Tom Zanussi , KOSAKI Motohiro , "H. Peter Anvin" , Jeremy Fitzhardinge , "Frank Ch. Eigler" , Tejun Heo In-Reply-To: <20100716120012.GC5377@nowhere> References: <20100714184642.GA9728@elte.hu> <20100714195617.GC22373@basil.fritz.box> <20100714200552.GA22096@Krystal> <20100714223116.GB14533@nowhere> <20100715141118.GA6417@nowhere> <20100716120012.GC5377@nowhere> Content-Type: text/plain; charset="UTF-8" Date: Fri, 16 Jul 2010 08:54:58 -0400 Message-ID: <1279284898.23610.36.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1194 Lines: 32 On Fri, 2010-07-16 at 14:00 +0200, Frederic Weisbecker wrote: > On Thu, Jul 15, 2010 at 07:51:55AM -0700, Linus Torvalds wrote: > > Such new page table created that might race is only about top level page > right? Otherwise it wouldn't race since the top level entries are shared > and then updates inside lower level pages are naturally propagated, if > I understood you well. > > So, if only top level pages that gets added can generate such lazily > mapping update, I wonder why I experienced this fault everytime with > my patches. > > I allocated 8192 bytes per cpu in a x86-32 system that has only 2 GB. > I doubt there is a top level page table update there at this time with > such a small amount of available memory. But still it faults once on > access. > > I have troubles to visualize the race and the problem here. > A few trace_printks and a tracing_off() on fault would probably show exactly what was happening ;-) -- Steve -- 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/