Hi Steven,
Steven Rostedt <rost...@goodmis.org> writes:
> On Mon, 5 Feb 2024 07:53:40 +0100
> Sven Schnelle <sv...@linux.ibm.com> wrote:
>
>> tracer_tracing_is_on() checks whether record_disabled is not zero. This
>> checks both the record_disabled counter and the RB_BUFFER_OFF flag.
>> Reading the source it looks like this function should only check for
>> the RB_BUFFER_OFF flag. Therefore use ring_buffer_record_is_set_on().
>> This fixes spurious fails in the 'test for function traceon/off triggers'
>> test from the ftrace testsuite when the system is under load.
>>
>
> I've seen these spurious failures too, but haven't looked deeper into
> it. Thanks,
Another issue i'm hitting sometimes is this part:
csum1=`md5sum trace`
sleep $SLEEP_TIME
csum2=`md5sum trace`
if [ "$csum1" != "$csum2" ]; then
fail "Tracing file is still changing"
fi
This is because the command line was replaced in the
saved_cmdlines_buffer, an example diff between both files
is:
ftracetest-17950 [005] ..... 344507.002490: sched_process_wait:
comm=ftracetest pid=0 prio=120
ftracetest-17950 [005] ..... 344507.002492: sched_process_wait:
comm=ftracetest pid=0 prio=120
- stress-ng-fanot-17820 [006] d.h.. 344507.009901: sched_stat_runtime:
comm=stress-ng-fanot pid=17820 runtime=10000054 [ns]
+ <...>-17820 [006] d.h.. 344507.009901: sched_stat_runtime:
comm=stress-ng-fanot pid=17820 runtime=10000054 [ns]
ftracetest-17950 [005] d.h.. 344507.009901: sched_stat_runtime:
comm=ftracetest pid=17950 runtime=7417915 [ns]
stress-ng-fanot-17819 [003] d.h.. 344507.009901: sched_stat_runtime:
comm=stress-ng-fanot pid=17819 runtime=9983473 [ns]
- stress-ng-fanot-17820 [007] d.h.. 344507.079900: sched_stat_runtime:
comm=stress-ng-fanot pid=17820 runtime=9999865 [ns]
+ <...>-17820 [007] d.h.. 344507.079900: sched_stat_runtime:
comm=stress-ng-fanot pid=17820 runtime=9999865 [ns]
stress-ng-fanot-17819 [004] d.h.. 344507.079900: sched_stat_runtime:
comm=stress-ng-fanot pid=17819 runtime=8388039 [ns]
This can be improved by:
echo 32768 > /sys/kernel/tracing/saved_cmdlines_size
But this is of course not a fix - should we maybe replace the program
name with <...> before comparing, remove the check completely, or do
anything else? What do you think?
Thanks,
Sven
