Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757317Ab0GNWs7 (ORCPT ); Wed, 14 Jul 2010 18:48:59 -0400 Received: from mail-wy0-f174.google.com ([74.125.82.174]:46376 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754274Ab0GNWs5 (ORCPT ); Wed, 14 Jul 2010 18:48:57 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=pyaxmv4ZnUKTUD644YHQ+mpkp+HNE3acjvgeD6XB4fENVcQ1aU0C+Kj4yWqz08O7ry vREjYyCpFi77pGB5zvI9A0iHiNV+eY7qjhzjTMjz4qi8NHBEoetydSL1D2NVWGyfc5ps 1xBAscwIkiCUPzkHInSEkaC2Tynf3BIbWitZw= Date: Thu, 15 Jul 2010 00:48:55 +0200 From: Frederic Weisbecker To: Mathieu Desnoyers Cc: Linus Torvalds , Ingo Molnar , LKML , Andrew Morton , Peter Zijlstra , Steven Rostedt , Steven Rostedt , Thomas Gleixner , Christoph Hellwig , Li Zefan , Lai Jiangshan , Johannes Berg , Masami Hiramatsu , Arnaldo Carvalho de Melo , Tom Zanussi , KOSAKI Motohiro , Andi Kleen , "H. Peter Anvin" , Jeremy Fitzhardinge , "Frank Ch. Eigler" , Tejun Heo Subject: Re: [patch 1/2] x86_64 page fault NMI-safe Message-ID: <20100714224853.GC14533@nowhere> References: <20100714155804.049012415@efficios.com> <20100714170617.GB4955@Krystal> <20100714184642.GA9728@elte.hu> <20100714193652.GA13630@nowhere> <20100714221418.GA14533@nowhere> <20100714223107.GA2350@Krystal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100714223107.GA2350@Krystal> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1865 Lines: 52 On Wed, Jul 14, 2010 at 06:31:07PM -0400, Mathieu Desnoyers wrote: > * Frederic Weisbecker (fweisbec@gmail.com) wrote: > > On Wed, Jul 14, 2010 at 12:54:19PM -0700, Linus Torvalds wrote: > > > On Wed, Jul 14, 2010 at 12:36 PM, Frederic Weisbecker > > > wrote: > > > > > > > > There is also the fact we need to handle the lost NMI, by defering its > > > > treatment or so. That adds even more complexity. > > > > > > I don't think your read my proposal very deeply. It already handles > > > them by taking a fault on the iret of the first one (that's why we > > > point to the stack frame - so that we can corrupt it and force a > > > fault). > > > > > > Ah right, I missed this part. > > Hrm, Frederic, I hate to ask that but.. what are you doing with those percpu 8k > data structures exactly ? :) > > Mathieu So, when an event triggers in perf, we sometimes want to capture the stacktrace that led to the event. We want this stacktrace (here we call that a callchain) to be recorded locklessly. So we want this callchain buffer per cpu, with the following type: #define PERF_MAX_STACK_DEPTH 255 struct perf_callchain_entry { __u64 nr; __u64 ip[PERF_MAX_STACK_DEPTH]; }; That makes 2048 bytes. But per cpu is not enough for the callchain to be recorded locklessly, we also need one buffer per context: task, softirq, hardirq, nmi, as an event can trigger in any of these. Since we disable preemption, none of these contexts can nest locally. In fact hardirqs can nest but we just don't care about this corner case. So, it makes 2048 * 4 = 8192 bytes. And that per cpu. -- 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/