From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966437AbcA1OyD (ORCPT ); Thu, 28 Jan 2016 09:54:03 -0500 Received: from mail.efficios.com ([78.47.125.74]:60316 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965230AbcA1Ox7 (ORCPT ); Thu, 28 Jan 2016 09:53:59 -0500 Date: Thu, 28 Jan 2016 14:53:53 +0000 (UTC) From: Mathieu Desnoyers To: Peter Zijlstra Cc: rostedt , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, "Paul E. McKenney" Message-ID: <1504204180.6731.1453992833257.JavaMail.zimbra@efficios.com> In-Reply-To: <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> <20160128144705.GS6356@twins.programming.kicks-ass.net> Subject: Re: [RFC][BUG] tracer: Fails to work MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [78.47.125.74] X-Mailer: Zimbra 8.6.0_GA_1178 (ZimbraWebClient - FF44 (Linux)/8.6.0_GA_1178) Thread-Topic: tracer: Fails to work Thread-Index: jLfDhFD9Vqe8MuR3iemtfdrBY5RtCQ== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Jan 28, 2016, at 9:47 AM, Peter Zijlstra peterz@infradead.org wrote: > 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. The new kernel can allocate the buffers into separate "files" on the DAX in-RAM filesystem, so the old buffers would still be there even when running the new kernel. > > 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) On x86, many BIOS wipe the memory content even after a warm reset :( The most reliable solution I found on x86 is to use kexec() to boot into a new kernel, mount the DAX filesystem again and read the buffers from there. I currently have the persistent buffer support implemented for the lttng userspace tracer, but not yet for the kernel tracer. It's high on my todo priority list though :) Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com