Messages in this thread | | | Date | Fri, 2 Aug 2019 15:08:54 +0100 | From | Qais Yousef <> | Subject | Re: [PATCH 0/5] Fix FIFO-99 abuse |
| |
On 08/02/19 14:41, Peter Zijlstra wrote: > On Fri, Aug 02, 2019 at 11:26:12AM +0100, Qais Yousef wrote: > > > Yes a somewhat enforced default makes more sense to me. I assume you no longer > > want to put the kthreads that just need to be above OTHER in FIFO-1? > > I'm not sure, maybe, there's not that many of them, but possibly we add > another interface for them.
By the way, did you see this one which is set to priority 16?
https://elixir.bootlin.com/linux/v5.3-rc2/source/drivers/gpu/drm/msm/msm_drv.c#L523
> > > While at it, since we will cram all kthreads on the same priority, isn't > > a SCHED_RR a better choice now? I think the probability of a clash is pretty > > low, but when it happens, shouldn't we try to guarantee some fairness? > > It's never been a problem, and aside from these few straggler threads, > everybody has effectively been there already for years, so if it were a > problem someone would've complained by now.
Usually they can run on enough CPUs so a real clash is definitely hard.
I'm trying to collect data on that, if I find something interesting I'll share it.
> > Also; like said before, the admin had better configure.
I agree. But I don't think an 'admin' is an easily defined entity for all systems. On mobile, is it the SoC vendor, Android framework, or the handset/platform vendor/integrator?
In a *real* realtime system I think things are better defined. But usage of RT tasks on generic systems is the confusing part. There's no real ownership and things are more ad-hoc.
> > Also also, RR-SMP is actually broken (and nobody has cared enough to > bother fixing it).
If you can give me enough pointers to understand the problem I might be able to bother with it :-)
Thanks
-- Qais Yousef
| |