Hello, sorry about the delay.
On Fri, Jul 17, 2026 at 11:06:55AM +0100, Tvrtko Ursulin wrote:
> > + /*
> > + * Do not consume all CPUs with RT workers to avoid scheduler
> > + * starvation.
> > + */
> > + if (pool->attrs->prio == WQ_PRIO_RT) {
> > + unsigned int max = num_online_cpus();
> > +
> > + if (max > 2)
> > + max = max - 1;
> > + else
> > + max = 1;
> > +
> > + if (atomic_inc_return(&total_rtpri_workers) > max) {
> > + atomic_dec(&total_rtpri_workers);
> > + return NULL;
>
> Sashiko is warning me here this can create a deadlock when called from
> maybe_create_worker(). My apparently naive idea was that this would make it
> wait for a bit, until the load on the currently instantiated workers
> subsides, at which point need_to_create_worker() would say "not any more"
> and allow it to exit.
>
> But even more importantly, it is also warning me that strict CPU affinity
> creates per CPU threads.
>
> So my idea of global limit will just not work.
>
> Tejun, how does this sound to you? Are you okay without having the global
> limit of RT threads?
>
> I will await sending v4 with other fixes until we can close on this one. I
> also have some vacation pending so there may be a delay in my replies.
I don't think we need to limit the total number of workers. It's not a
meaningful protection anyway (is it ok if max-1 CPUs are pinned in RT?), the
DL server already provides forward progress protection, and it doesn't make
sense to design this assuming malicious / incompetent users.
Thanks.
--
tejun
