Messages in this thread | | | Date | Wed, 19 Oct 2022 12:23:15 +0100 | From | Qais Yousef <> | Subject | Re: [PATCH RFC v4 2/3] sched: Avoid placing RT threads on cores handling long softirqs |
| |
On 10/17/22 20:42, John Stultz wrote:
> > > + return ret; > > > +} > > > +#else > > > +#define __use_softirq_opt 0 > > > +static bool cpu_busy_with_softirqs(int cpu) > > > +{ > > > + return false; > > > +} > > > +#endif /* CONFIG_RT_SOFTIRQ_OPTIMIZATION */ > > > + > > > +static bool rt_task_fits_cpu(struct task_struct *p, int cpu) > > > > To me, the new name is unfortunate, since it strips a notion > > of the reason. Instead, "CPU un/fits, because of capacity" it > > reads as "CPU un/fits, because of ..." what? > > As with all complicated questions: "It depends" :) On the kernel > config specifically. > > The earlier version of the patch had: > rt_task_fits_capacity_and_may_preempt() but Qais suggested it be > switched to the generic "fits_cpu" as it would depend on the kernel > config as to which aspect of "fit" was being considered. > > I guess it could be rt_task_fits_capacity_and_softirq_free() ?
My line of thinking is that we have multiple reasons which could potentially come and go. Having a simple generic name is future proof to the details of the reason.
For example, in the future we might find a better way to handle the softirq conflict and remove this reason; or we might find a new 'reason' is required. Documenting that in the function header (if required, I see the one line implementation is self descriptive so far) rather than in name made more sense to me, hence the suggestion.
I am already aware of another new reason required to handle thermal pressure when checking for capacity [1]. The discussion has stalled, but the problem is still there and we'd need to address it. So I expect this code will be massaged somewhat in the near future.
Sticking to rt_task_fits_cpu() will reduce the churn IMHO. But if you really prefer something else, works for me :-)
[1] https://lore.kernel.org/lkml/20220514235513.jm7ul2y6uddj6eh2@airbuntu/
Cheers
-- Qais Yousef
| |