Re: [PATCH v3 1/2] timer: add a function to adjust timeouts to be upper bound

[Thomas Gleixner <tglx@linutronix.de>]

On Wed, Apr 06 2022 at 11:52, Artem Savkov wrote:

> On Tue, Apr 05, 2022 at 05:33:23PM +0200, Thomas Gleixner wrote:
>> On Sat, Apr 02 2022 at 08:55, Artem Savkov wrote:
>> > Is it possible to determine the upper limit of error margin here? My
>> > assumption is it shouldn't be very big, so maybe it would be enough to
>> > account for this when adjusting timeout at the edge of a level.
>> > I know this doesn't sound good but I am running out of ideas here.
>> 
>> Let's just take a step back.
>> 
>> So we know, that the maximal error margin in the wheel is 12.5%, right?
>> That means, if you take your relative timeout and subtract 12.5% then
>> you are in the right ballpark and the earliest expiry will not be before
>> that point obviously, but it's also guaranteed not to expire later than
>> the original timeout. Obviously this will converge towards the early
>> expiry the longer the timeouts are, but it's bound.
>
> Ok, I was trying to avoid a "hole" where any timeout < LVL_GRAN(lvl)
> would be always substantially (LVL_GRAN(lvl) - LVL_GRAN(lvl - 1)) early
> but looks like this is unavoidable with this approach.

Right, but where is the problem you are trying to solve? Does it matter
whether the keepalive timer fires after 28 minutes or after 30 minutes?

Not really. All you are about that it does not fire 2 minutes late. So
what?

>> Also due to the properties of the wheel, the lag of base::clk will
>> obviously only affect those levels where lag >= LVL_GRAN(level).
>
> Is this true? Won't it be enough for the lag to be just
> lag >= (LVL_START(lvl) - adjusted_timeout) for the cases when we cross
> level boundary on adjustment?

The corner case is at the next boundary level. The resulting worst case
there is one jiffy, which is below noise level :)

Thanks,

        tglx