On a kernel with preemption none or voluntary, 'ethtool -d'
on a qede network device can cause a big latency spike.
The biggest part of it is the loop in qed_grc_dump_ctx_data.
The function is called only from the .get_size and .perform_dump
callbacks for the "grc" feature defined in qed_features_lookup[].
As far as I can see, they are used in:
- qed's devlink healh reporter .dump op
- qede's ethtool get_regs/get_regs_len/get_dump_data ops
- qedf's qedf_get_grc_dump, called from:
- qedf_sysfs_write_grcdump - "grcdump" sysfs attribute write
- qedf_wq_grcdump - a workqueue
It is safe to sleep in all of them.
Let's insert a cond_resched() in the outer loop to let other tasks run.
Measured using this script:
#!/bin/bash
DEV=ens3f1
echo wakeup_rt > /sys/kernel/tracing/current_tracer
echo 0 > /sys/kernel/tracing/tracing_max_latency
echo 1 > /sys/kernel/tracing/tracing_on
echo "Setting the task CPU affinity"
taskset -p 1 $$ > /dev/null
echo "Starting the real-time task"
chrt -f 50 bash -c 'while sleep 0.01; do :; done' &
sleep 1
echo "Running: ethtool -d $DEV"
time ethtool -d $DEV > /dev/null
kill %1
echo 0 > /sys/kernel/tracing/tracing_on
echo "Measured latency: $(</sys/kernel/tracing/tracing_max_latency) us"
echo "To see the latency trace: less /sys/kernel/tracing/trace"
The patch lowers the latency from 180 ms to 53 ms on my test system with
voluntary preemption.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Link: https://patch.msgid.link/20240930201307.330692-3-mschmidt@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>