Date: Wed, 8 Mar 2017 14:36:11 -0500
From: Steven Rostedt <rostedt@goodmis.org>
To: Todd Brandt <todd.e.brandt@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC][PATCH 0/4] tracing: Allow function tracing to start
 earlier in boot up
Message-ID: <20170308143611.3656b873@gandalf.local.home>
In-Reply-To: <1489001545.7212.61.camel@linux.intel.com>
References: <20170307212833.964734229@goodmis.org>
        <1489000557.7212.58.camel@linux.intel.com>
        <1489001545.7212.61.camel@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1522
Lines: 36

On Wed, 08 Mar 2017 11:32:25 -0800
Todd Brandt <todd.e.brandt@linux.intel.com> wrote:

> On Wed, 2017-03-08 at 11:15 -0800, Todd Brandt wrote:
> > On Tue, 2017-03-07 at 16:28 -0500, Steven Rostedt wrote:  
> > > I've had people ask about moving tracing up further in the boot process.
> > > This patch series looks at function tracing only. It allows for tracing
> > > (and function filtering) to be moved right after memory is initialized.
> > > To have it happen before memory initialization would require a bit more
> > > work with allocating the ring buffer. But this is a start.  
> > 
> > I just tested out the patch and it does move function trace up to about
> > 100ms from boot which is nice. What I'd really like is for graph trace
> > to start sooner as well.

I can add this. I just wanted this out first.

The one part I want people to notice is the last patch where I add a
hook into the free mem reserve. I'll ping the mm folks to make sure
they are OK with that.


> > [    0.440232] calling  init_per_zone_wmark_min+0x0/0x73 @ 1
> > [    0.440249] calling  init_zero_pfn+0x0/0x3d @ 1
> > [    0.440257] calling  memory_failure_init+0x0/0xa4 @ 1
> > [    0.440266] calling  cma_init_reserved_areas+0x0/0x1cd @ 1
> > [    0.440275] calling  fsnotify_init+0x0/0x26 @ 1  
> 
> Oops, no sooner than 5 minutes after I sent this did I figure out
> there's a trace_clock kernel parameter (not in kernel-parameters.txt).
> Once I set it to global all is well. Never mind :)

I was just about to ask ;-)

-- Steve