On Mon, 2026-05-18 at 09:44 +0200, Nam Cao wrote: > Gabriele Monaco <[email protected]> writes: > > On Mon, 2026-05-11 at 13:55 +0200, Nam Cao wrote: > > > That can work, but not ideal, because hrtimer will not be usable. > > > > Why not? If we have HA_TIMER_WHEEL , we'd use timer and expire, if we have > > HA_TIMER_HRTIMER we'd only need hrtimer with it's hrtimer_get_expires(): > > > > union { > > struct hrtimer hrtimer; > > struct { > > struct timer_list timer; > > u64 expire; /* Explicitly store the armed budget */ > > }; > > > > we already can't use timer and hrtimer interchangeably. > > What am I missing here? > > Ah, now I understand the trick, thanks. > > We already have an "expires" field in struct timer_list. But I am not > sure if we are supposed to touch that field. Your proposal looks safer.
Yeah and even if we did, that'd be jiffy-granularity, so not good if the clock is ns-based. Let me sketch it out. Anyway back to the patch, you need to fix the build for HA_TIMER_HRTIMER as well (too many arguments to function ‘ha_invariant_passed_ns’; expected 3, have 4), and the title should s/Simply/Simplify/ Thanks, Gabriele > > > > Looking at the throttle monitor again, is it possible to rewrite > > > runtime_left_ns() to read .dl_runtime instead of .runtime? I don't know > > > the deadline schedule very well, but I think .dl_runtime is not changing > > > like .runtime? > > > > In theory yes, but since the runtime is consumed only when running, we > > cannot > > just set the timeout once. We either save how much was consumed somewhere or > > do > > some start/pause mechanism. > > Neither looks simpler to me. > > Understood. > > Nam
