From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755934AbYIYRcH (ORCPT ); Thu, 25 Sep 2008 13:32:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752892AbYIYRbz (ORCPT ); Thu, 25 Sep 2008 13:31:55 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:41436 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752407AbYIYRby (ORCPT ); Thu, 25 Sep 2008 13:31:54 -0400 Date: Thu, 25 Sep 2008 10:29:57 -0700 (PDT) From: Linus Torvalds To: Mathieu Desnoyers cc: Martin Bligh , Peter Zijlstra , Steven Rostedt , linux-kernel@vger.kernel.org, Ingo Molnar , Thomas Gleixner , Andrew Morton , prasad@linux.vnet.ibm.com, "Frank Ch. Eigler" , David Wilder , hch@lst.de, Tom Zanussi , Steven Rostedt Subject: Re: [RFC PATCH 1/3] Unified trace buffer In-Reply-To: <20080925171559.GB29392@Krystal> Message-ID: References: <20080924051400.195780424@goodmis.org> <1222268595.16700.149.camel@lappy.programming.kicks-ass.net> <33307c790809240847r31c8b683na15ff5488b60d25b@mail.gmail.com> <1222272686.16700.162.camel@lappy.programming.kicks-ass.net> <33307c790809240949i3026170i8f9ac1d67a0fcf00@mail.gmail.com> <33307c790809241054n47addd27hef90930f109599fd@mail.gmail.com> <20080924205334.GB12248@Krystal> <20080925171559.GB29392@Krystal> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 25 Sep 2008, Mathieu Desnoyers wrote: > > We could use a page header instead to contain the "unused_size" > information. Absolutely. There's no one way to do this. > I would prefer to put the extended timestamp within the event header > instead of creating a separate entry for this for atomicity concerns > (what happens if a long interrupt executes between the TSCExtend marker > event and the event expecting to be written right next to it ?). The log entries should be reserved with interrupts disabled anyway, and they are per-CPU, so there are no atomicity issues. For NMI's, things get more exciting. I'd really prefer NMI's to go to a separate ring buffer entirely, because otherwise consistency gets really hard. Using lockless algorithms for a variable-sized pool of pages is a disaster waiting to happen. I don't think we can currently necessarily reasonably trace NMI's, but it's something to keep in mind as required support eventually. Linus