[LITMUS^RT] st-job-stats

[Martinez Garcia Jorge Luis (PS-EC/ESB2)]

Hello Björn, 
W.r.t your first point, my config file now looks like this (The system RAM of the RPi3 is 1 Gb):

#
# Scheduling
#
CONFIG_PLUGIN_PFAIR=y
# CONFIG_RELEASE_MASTER is not set
CONFIG_SYNCHRONOUS_RELEASE_RESETS_JOB_ID=y
CONFIG_PREFER_LOCAL_LINKING=y
CONFIG_LITMUS_QUANTUM_LENGTH_US=1000
CONFIG_BUG_ON_MIGRATION_DEADLOCK=y

# 
# Real-Time Synchronization
#
CONFIG_NP_SECTION=y
CONFIG_LITMUS_LOCKING=y

# 
# Performance Enhancements
#
CONFIG_ALLOW_EARLY_RELEASE=y
# CONFIG_EDF_TIE_BREAK_LATENESS is not set
# CONFIG_EDF_TIE_BREAK_LATENESS_NORM is not set
# CONFIG_EDF_TIE_BREAK_HASH is not set
CONFIG_EDF_PID_TIE_BREAK=y

#
# Tracing
#
CONFIG_FEATHER_TRACE=y
CONFIG_SCHED_TASK_TRACE=y
CONFIG_SCHED_TASK_TRACE_SHIFT=9
# CONFIG_SCHED_LITMUS_TRACEPOINT is not set
CONFIG_SCHED_OVERHEAD_TRACE=y
CONFIG_SCHED_OVERHEAD_TRACE_SHIFT=25
# CONFIG_SCHED_DEBUG_TRACE is not set
# CONFIG_REPORT_TIMER_LATENCY is not set

However, once I compiled the kernel and run the experiment, I got the same number of "Failed trace writes".  How can I check if my trace buffers was actually incremented? 
By the way, do I have to recompile liblitmus and feather-trace-tool for the new kernel with larger trace buffer (CONFIG_SCHED_OVERHEAD_TRACE_SHIFT=25)?

Best,
Jorge



-----Original Message-----
From: litmus-dev <litmus-dev-bounces at lists.litmus-rt.org> On Behalf Of Björn Brandenburg
Sent: Freitag, 21. September 2018 11:38
To: litmus-dev at lists.litmus-rt.org
Subject: Re: [LITMUS^RT] st-job-stats

On 20. Sep 2018, at 18:58, Martinez Garcia Jorge Luis (PS-EC/ESB2) <JorgeLuis.MartinezGarcia at de.bosch.com> wrote:
> 
> Your guess seems to be right. The "hole" takes place for all tasks simultaneously. Even dmesg reports " Failed trace writes: 133535 ". What can I do to overcome this issue? 


First, ake the trace buffers as large as you can make them, given the amount of system RAM that you have (kernel config). 

Second, run the tracer processes on a core that doesn’t host RT tasks (or that has only a light load). 

Third, but I wouldn’t really recommend this if the other two option work, make the tracer a real-time process in a reservation itself. 

Best,
Björn


_______________________________________________
litmus-dev mailing list
litmus-dev at lists.litmus-rt.org
https://lists.litmus-rt.org/listinfo/litmus-dev