[PATCH 2/3] powerpc/xmon: Disable and enable tracing command

[Naveen N. Rao]

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