[...] > I'm all for a general solution, but that's far, far beyond my SRCU knowledge > level. > I was quite proud of myself for piecing together the incurred-delay. :-) > > FYI, I'm going to be unavailable for ~2 weeks. Nikita (Cc'd) can likely help > test > potential fixes. > Hi Sean, hi Nikita,
Some data points on the RFC scenario. The setup follows the pattern discussed in the RFC: a call_srcu()-like path that can start a non-expedited GP, followed by a synchronize_srcu_expedited()-like wait on the same SRCU instance. KVM selftest setup, BPF tracing.Single VM, single vCPU. Guest holds a long measured window (~8s, fixed in selftest). Baseline: In 5 recent 10-run batches, the no-preemption case produced a single >1ms sample in total. With same-CPU preemption: >1ms reproduces consistently and shows up in most runs. For >1ms samples, sched_switch/off-CPU attribution lines up with switch-out in the same measured window. In this setup, >1ms is mostly off-CPU time,not continuous in-CPU execution. Question on the original report: when synchronize_srcu_expedited() delay was observed, was the host mostly idle/bursty, or under steady load? Can share repro details if needed. Thanks, Kunwu Chan
