Re: [RFC PATCH v3 2/3] sched: Avoid placing RT threads on cores handling long softirqs
From: Qais Yousef
Date: Wed Oct 05 2022 - 11:46:58 EST
On 10/04/22 09:50, David Laight wrote:
> > That's fair. Digging through the patch history in the Android trees,
> > the first pass was for all softirqs but then restricted to remove
> > known short-running ones.
> > From the bug history and what I can directly reproduce, the net and
> > block softirqs have definitely caused trouble, but I don't see a
> > specific example from TASKLET, so I'm ok dropping that for now, and
> > should we get specific evidence we can argue for it in a future patch.
> > So I'll drop TASKLET from the list here. Thanks for the suggestion!
> I've also seen the code that finally frees memory freed under rcu
> take a long time.
> That was a workload sending a lot of UDP/RTP from a raw socket using
> IP_HDRINC - each send allocated a structure (fib?) that was freed from
> the rcu (timer?) softint callback.
I'm assuming this is a network driver that using RCU callback to free some
> But, actually, one of the biggest causes of RT wakeup latency
> was a normal thread looping without a cond_resched() call.
> In my case some graphics driver doing page flushes of the
> display memory.
Were these drivers that cause these problem in-tree or out-of-tree?