On 2017/08/01 11:21AM, Breno Leitao wrote:
> Hi Naveen,
>
> On Tue, Aug 01, 2017 at 12:10:24PM +0530, Naveen N. Rao wrote:
> > On 2017/07/31 02:22PM, Breno Leitao wrote:
> > > If tracing is enabled and you get into xmon, the tracing buffer
> > > continues to be updated, causing possible loss of data due to buffer
> > > overflow and unnecessary tracing information coming from xmon functions.
> > >
> > > This patch adds a new option that allows the tracing to be disabled and
> > > re-enabled from inside xmon.
> >
> > How is this new option useful? In the next patch, you disable tracing by
> > default -- in what scenario do you expect to have to re-enable tracing
> > from within xmon?
>
> I see it being useful on two different scenarios:
>
> 1) You can reenable tracing if you want to call a function from xmon
> (with 'p'), or even for code stepping (with 's').
Hmm... those are just debugging aids, so I don't see why enabling the
function tracer helps, unless you're debugging the tracer itself..
>
> 2) You may also want to reenable tracing once you resume from xmon with
> 'zr'.
'zr' is for reboot, so not sure what you meant there...
If tracing was enabled before we went into xmon, I think that we should
just restore it by default.
>
> > > + case 'v':
> > > + if (tracing_is_on()) {
> > > + printk("Disabling tracing\n");
> > > + tracing_enabled = 0;
> > > + tracing_off();
> >
> > This only disables trace buffer updates - ftrace (and all its callbacks,
> > et al) remains active, which isn't desirable.
>
> Why isn't it desirable? In fact, I thought it would be *the* desirable
> function to call, since it does not do a lot of stuff, as disabling
> tracing, in xmon mode, but, just disable the tracing buffer to be updated.
>
> Since we are in xmon, we are in a very bad state, and something went
> very wrong. Disabling the whole tracing might not be what we want to do
> in this scenario, since it can hit the broken subsystem causing xmon to
> fail.
>
> For bad state scenario, I understand that it is desirable to be less
> instrusive as possible, and tracing_off() does exactly it.
My concern was that we will still go through all the callbacks and I was
wondering if we could get rid of that. However, I don't see any easy way
to do that with the current ftrace infrastructure.
>
> > Can you see if this works for you:
> > https://patchwork.ozlabs.org/patch/769611/
>
> Well, I understand that this patch solves a different issue, this does
> not reduce the tracing caused by function tracer after you got into into
> xmon.
>
> As for example, with your patch applied, I can see a lot of xmon
> functions polluting the tracing buffer as:
>
> 1:mon> dt
> [ 359.196593] Dumping ftrace buffer:
> [ 359.196689] ---------------------------------
> [ 359.196904] 1) | xmon_printf() {
> <110+ lines snipped>
> [ 359.197727] 1) + 22.930 us | }
> [ 359.199405] 1) | skipbl() {
> <50+ lines snipped>
> [ 359.225069] 1) + 23.750 us | }
>
>
> Since tracing continues to be enabled during xmon, these messages
> continue to show up. That is exactly what I am trying to avoid with this
> current patchset. Avoiding all xmon-related tracing is my main goal.
Ok, makes sense.
Thanks,
Naveen
