Current xmon 'dt' command dumps the tracing buffer for all the CPUs,
which makes it possibly hard to read the logs due to the fact that most
of powerpc machines currently have many CPUs. Other than that, the CPU
lines are interleaved in the ftrace log.
This new option just dumps the ftrace buffer for the current CPU.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/xmon/xmon.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
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.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/xmon/xmon.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
Currently tracing is enabled from inside xmon, which may cause some
noise into the tracing buffer, and makes it harder to find what, in
the tracing buffer, are kernel non-xmon functions and what is xmon
'noise' (as printk()s and terminal functions tracing).
This patch simple disables it by default, showing a better trace output
of the failing functions just before it gets into xmon.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/xmon/xmon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Naveen N. Rao <hidden> Date: 2017-08-01 06:41:48
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?
This only disables trace buffer updates - ftrace (and all its callbacks,
et al) remains active, which isn't desirable. Can you see if this works
for you:
https://patchwork.ozlabs.org/patch/769611/
- Naveen
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:
quoted
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').
2) You may also want to reenable tracing once you resume from xmon with
'zr'.
quoted
+ 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.
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.
Thanks for your review,
Breno
From: Naveen N. Rao <hidden> Date: 2017-08-02 13:22:23
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:
quoted
On 2017/07/31 02:22PM, Breno Leitao wrote:
quoted
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.
quoted
quoted
+ 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.
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.
On Wed, Aug 02, 2017 at 06:51:24PM +0530, Naveen N. Rao wrote:
On 2017/08/01 11:21AM, Breno Leitao wrote:
quoted
Hi Naveen,
On Tue, Aug 01, 2017 at 12:10:24PM +0530, Naveen N. Rao wrote:
quoted
On 2017/07/31 02:22PM, Breno Leitao wrote:
quoted
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..
quoted
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...
I meant 'x' in fact, which means 'exit monitor and recover'. This will
resume the kernel after getting into xmon.
If tracing was enabled before we went into xmon, I think that we should
just restore it by default.
Makes sense. So, I will get ride of this 'v' feature and disable tracing
when entering the xmon, and reenabling it on recovering. That way, we
will avoid xmon functions showing up on the tracing buffer.
I will send a new patchset soon!
Thanks,
Breno