From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965765AbcA1OrT (ORCPT ); Thu, 28 Jan 2016 09:47:19 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:41875 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932685AbcA1OrQ (ORCPT ); Thu, 28 Jan 2016 09:47:16 -0500 Date: Thu, 28 Jan 2016 15:47:05 +0100 From: Peter Zijlstra To: Mathieu Desnoyers Cc: rostedt , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, "Paul E. McKenney" Subject: Re: [RFC][BUG] tracer: Fails to work Message-ID: <20160128144705.GS6356@twins.programming.kicks-ass.net> References: <20160128080859.GB6357@twins.programming.kicks-ass.net> <1069612139.6639.1453988280286.JavaMail.zimbra@efficios.com> <20160128135733.GQ6356@twins.programming.kicks-ass.net> <1616014588.6697.1453991896740.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1616014588.6697.1453991896740.JavaMail.zimbra@efficios.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 28, 2016 at 02:38:16PM +0000, Mathieu Desnoyers wrote: > ----- On Jan 28, 2016, at 8:57 AM, Peter Zijlstra peterz@infradead.org wrote: > > > On Thu, Jan 28, 2016 at 01:38:00PM +0000, Mathieu Desnoyers wrote: > > > >> Thoughts ? > > > > So ideally dumping the trace data would not depend on any of that, > > because I can break it all :-) > > > > Not being able to access the trace data completely and utterly defeats > > the purpose of having a tracer in the first place. > > One item I have on my todo list is to allow mapping > the tracer buffers (lttng in my case) onto RAM that > persists across reboots/kexec using dax and the pmem > driver. Since the original system is clearly inactive > after a reboot, we can read the buffers from memory > without caring about synchronization. I would expect the new kernel to use the same buffer for its tracing, right? After all, there's no distinction between the old and new kernel except a reboot. In which case, my kernels often start babbling the moment I boot. So I need to take care not to scribble the old data. > That would be one possible way of handling your > snapshot-of-buggy-kernel-trace-buffers use-case. Now I wonder if my ipmipower -r is a warn reset :-) (I'm assuming the pmem/dax stuff would simply use regular RAM to back this stuff)