All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qais Yousef <qais.yousef@arm.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: 'John Stultz' <jstultz@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Connor O'Brien <connoro@google.com>,
	John Dias <joaodias@google.com>, Rick Yiu <rickyiu@google.com>,
	John Kacur <jkacur@redhat.com>,
	Chris Redpath <chris.redpath@arm.com>,
	Abhijeet Dharmapurikar <adharmap@quicinc.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"kernel-team@android.com" <kernel-team@android.com>,
	"J . Avila" <elavila@google.com>
Subject: Re: [RFC PATCH v3 2/3] sched: Avoid placing RT threads on cores handling long softirqs
Date: Wed, 5 Oct 2022 16:46:47 +0100	[thread overview]
Message-ID: <20221005154647.vok6unu3vnzxp74d@wubuntu> (raw)
In-Reply-To: <efbeb4b069384aa39a80d606d14ec833@AcuMS.aculab.com>

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
memory?

> 
> 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?


Thanks

--
Qais Yousef

  reply	other threads:[~2022-10-05 15:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21  1:25 [RFC][PATCH v3 0/3] Softirq -rt Optimizations John Stultz
2022-09-21  1:25 ` [RFC PATCH v3 1/3] softirq: Add generic accessor to percpu softirq_pending data John Stultz
2022-09-29 10:05   ` Heiko Carstens
2022-09-21  1:25 ` [RFC PATCH v3 2/3] sched: Avoid placing RT threads on cores handling long softirqs John Stultz
2022-09-28 12:55   ` Qais Yousef
2022-10-03 16:55     ` John Stultz
2022-10-03 17:47       ` John Stultz
2022-10-04  9:50       ` David Laight
2022-10-05 15:46         ` Qais Yousef [this message]
2022-10-05 15:31       ` Qais Yousef
2022-09-21  1:25 ` [RFC PATCH v3 3/3] softirq: defer softirq processing to ksoftirqd if CPU is busy with RT John Stultz
2022-09-28 12:56   ` Qais Yousef
2022-10-03 18:43     ` John Stultz
2022-09-28 13:00 ` [RFC][PATCH v3 0/3] Softirq -rt Optimizations Qais Yousef
2022-09-28 13:51   ` David Laight
2022-09-28 15:56     ` Qais Yousef
2022-09-28 16:19       ` David Laight
2022-09-29 10:47         ` Qais Yousef

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221005154647.vok6unu3vnzxp74d@wubuntu \
    --to=qais.yousef@arm.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=adharmap@quicinc.com \
    --cc=chris.redpath@arm.com \
    --cc=connoro@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=elavila@google.com \
    --cc=jkacur@redhat.com \
    --cc=joaodias@google.com \
    --cc=jstultz@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rickyiu@google.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.