When CONFIG_DEBUG_HARD_LOCKS is enabled, the lock dependency engine (CONFIG_LOCKDEP) which helps in tracking down deadlocks and other locking-related issues is also enabled for Dovetail’s hard locks, which underpins most of the serialization mechanisms the EVL core uses.
This is nice as it has the lock validator monitor the hard spinlocks
EVL uses too. However, this comes with a high price latency-wise:
seeing hundreds of microseconds spent in the validator with hard
interrupts off from time to time is not uncommon. Running the latency
monitoring utility (aka
latmus) which is part of
libevl in this
configuration should give you pretty ugly numbers.
In short, it is fine enabling CONFIG_DEBUG_HARD_LOCKS for debugging some locking pattern in EVL, but you won’t be able to meet real-time requirements at the same time in such configuration.
Isolating some CPUs on the kernel command line using the isolcpus= option, in order to prevent the load balancer from offloading in-band work to them is not only a good idea with PREEMPT_RT, but for any dual kernel configuration too.
By doing so, having some random in-band work evicting cache lines on a CPU where real-time threads briefly sleep is less likely, increasing the odds of costly cache misses, which translates positively into the latency numbers you can get. Even if EVL’s small footprint core has a limited exposure to such kind of disturbance, saving a handful of microseconds is worth it when the worst case figure is already within tenths of microseconds.
On single-core hardware, some out-of-line code may still be executed for dealing with various types of spinlock with a SMP build, which translates into additional CPU branches and cache misses. On low end hardware, this overhead may be noticeable.
Therefore, if you neither need SMP support nor kernel debug options which depend on instrumenting the spinlock constructs (e.g. CONFIG_DEBUG_PREEMPT), you may want to disable all the related kernel options, starting with CONFIG_SMP.