proposed change to cyclictest -b <n> behavior

proposed change to cyclictest -b <n> behavior

[Clark Williams]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

All,

I was updating cyclictest in the rt-tests package to handle the 3.0-rt
kernel changes and was talking to Steven Rostedt about ftrace options
and he suggested this change to the -b (breaktrace) option: use event
tracing rather than function tracing by default. 

The default for -b is to enable the function tracer. What Steven is
suggesting is to trace using the already installed tracepoints to get
an idea of where a latency occurs, rather than incurring the function
tracer (mcount) overhead by default. This is equivalent to doing:

# cyclictest -b 1000 --event --tracer=nop

I like the idea, but wanted to ask the cyclictest users if this would
break anything. I actually think that the whole ftrace interface for
cyclictest needs to be overhauled, since it was done very ad hoc and is
not all that well thought out, but I'm not quite ready to take that on
now. 

So, anyone object to me making this change?

Clark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: proposed change to cyclictest -b <n> behavior

[Nivedita Singhvi]

Clark Williams wrote:
> All,
> 
> I was updating cyclictest in the rt-tests package to handle the 3.0-rt
> kernel changes and was talking to Steven Rostedt about ftrace options
> and he suggested this change to the -b (breaktrace) option: use event
> tracing rather than function tracing by default. 
> 
> The default for -b is to enable the function tracer. What Steven is
> suggesting is to trace using the already installed tracepoints to get
> an idea of where a latency occurs, rather than incurring the function
> tracer (mcount) overhead by default. This is equivalent to doing:
> 
> # cyclictest -b 1000 --event --tracer=nop
> 
> I like the idea, but wanted to ask the cyclictest users if this would
> break anything. I actually think that the whole ftrace interface for
> cyclictest needs to be overhauled, since it was done very ad hoc and is
> not all that well thought out, but I'm not quite ready to take that on
> now. 
> 
> So, anyone object to me making this change?


This sounds good to me. I'd prefer not to incur the extra
unnecessary overhead, too.

thanks,
Nivedita