On 05/31/24 08:30, Sebastian Andrzej Siewior wrote: > On 2024-05-30 12:10:44 [+0100], Qais Yousef wrote: > > > This is not consistent because IMHO the clock setup & slack should be > > > handled equally. So I am asking the sched folks for a policy and I am > > > leaning towards looking at task-policy in this case instead of prio > > > because you shouldn't do anything that can delay. > > > > Can't we do that based on is_soft/is_hard flag in hrtimer struct when we apply > > the slack in hrtimer_set_expires_range_ns() instead? > > We need to decide on a policy first. > You don't want to add overhead on each invocation plus some in-kernel > ask for delta. ->is_soft is not a good criteria. The suggestion was not to check policy or priority but dictate the behavior based on hrtimer properties set at init. Which agrees with your thinking. I think the check for policy at init to enforce a behavior is borderline hack by the way and better to get an explicit request from a task and let the HRTIMER comply adequately without checking for policies anywhere. Whether this property should be inherited or not is a good question and I think is the policy you're after here. Proxy Execution would probably handle all this inheritance problems transparently, so we need not think much about it if we agree proxy execution is the way to deal with all those inheritance problems. There are always exceptions though.. So worth a think. I'll drop this patch as this discussion has diverged to something else now. I'll leave this here until others get a chance to comment with their views too. Cheers -- Qais Yousef
