On 5/6/19 5:22 AM, Marcelo Tosatti wrote: > On Mon, Apr 15, 2019 at 05:12:13PM -0300, Marcelo Tosatti wrote: >> For isolated CPUs, we'd like to skip awakening ktimersoftd >> (the switch to and then back from ktimersoftd takes 10us in >> virtualized environments, in addition to other OS overhead, >> which exceeds telco requirements for packet forwarding for >> 5G) from the sched tick. >> >> The patch "timers: do not raise softirq unconditionally" from Thomas >> attempts to address that by checking, in the sched tick, whether its >> necessary to raise the timer softirq. Unfortunately, it attempts to grab >> the tvec base spinlock which generates the issue described in the patch >> "Revert "timers: do not raise softirq unconditionally"". >> >> tvec_base->lock protects addition of timers to the wheel versus >> timer interrupt execution. >> >> This patch does not grab the tvec base spinlock from irq context, >> but rather performs a lockless access to base->pending_map. >> >> It handles the the race between timer addition and timer interrupt >> execution by unconditionally (in case of isolated CPUs) raising the >> timer softirq after making sure the updated bitmap is visible >> on remote CPUs. >> >> This patchset reduces cyclictest latency from 25us to 14us >> on my testbox. >> >> > > Ping? > Hi Marcelo, I've been running your patches with lockdep and other debug options and did not find any problem of this kind. Also, I did not find any kind of timing regressions in tests with the PREEMPT RT... -- Daniel
