Messages in this thread | | | From | Lorenzo Colitti <> | Date | Wed, 21 Apr 2021 23:08:19 +0900 | Subject | Re: [PATCH] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() |
| |
On Tue, Apr 20, 2021 at 11:19 PM Thomas Gleixner <tglx@linutronix.de> wrote: > 1) hrtimer is contrary to timer_list not really suited for high > frequency start/cancel/start/... cycles of a timer. It's optimized > for the start and expire precisely case.
Ack. This is not what the f_ncm gadget code needs. It just needs a timer to fire "about 300us after the last packet submitted". Under load the timer will almost never fire since there will always be another packet coming. So the speed of adding/updating the timer is much more important than the accuracy. We will try to move it to timer_list.
> I assume that's an ARM64 system. ARM64 CPUs have an architected per > CPU timer where the reprogramming is pretty fast as it's next to > the CPU, but who knows what your system is using.
This system appears to be using timer hardware that is... slow to program (microseconds). We're looking at whether it's possible to use the arch timer instead.
> Now in the meantime I looked into __hrtimer_start_range_ns() whether > that double reprogram can be avoided without creating a total trainwreck > and imposing penalty on all sensible use cases. Completely untested > patch below should do the trick and it's not ugly enough that I hate it > with a passion.
I tested this and in my simple benchmark, the double calls are gone and hrtimer_start calls tick_program_event approximately once (more precisely, 90.06% of the time; sometimes it doesn't call it at all). This is not enough to cancel the regression we're seeing because the previous code would pretty much never call tick_program_event at all. But it's definitely better.
| |