From: Mike Galbraith <bitbucket@online.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: frank.rowand@am.sony.com,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-rt-users <linux-rt-users@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Carsten Emde <C.Emde@osadl.org>, John Kacur <jkacur@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Clark Williams <clark.williams@gmail.com>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [RFC][PATCH RT 3/4] sched/rt: Use IPI to trigger RT task push migration instead of pulling
Date: Tue, 11 Dec 2012 08:07:43 +0100 [thread overview]
Message-ID: <1355209663.7057.77.camel@marge.simpson.net> (raw)
In-Reply-To: <1355190830.17101.280.camel@gandalf.local.home>
On Mon, 2012-12-10 at 20:53 -0500, Steven Rostedt wrote:
> On Mon, 2012-12-10 at 17:15 -0800, Frank Rowand wrote:
>
> > I should have also mentioned some previous experience using IPIs to
> > avoid runq lock contention on wake up. Someone encountered IPI
> > storms when using the TTWU_QUEUE feature, thus it defaults to off
> > for CONFIG_PREEMPT_RT_FULL:
> >
> > #ifndef CONFIG_PREEMPT_RT_FULL
> > /*
> > * Queue remote wakeups on the target CPU and process them
> > * using the scheduler IPI. Reduces rq->lock contention/bounces.
> > */
> > SCHED_FEAT(TTWU_QUEUE, true)
> > #else
> > SCHED_FEAT(TTWU_QUEUE, false)
> >
>
> Interesting, but I'm wondering if this also does it for every wakeup? If
> you have 1000 tasks waking up on another CPU, this could potentially
> send out 1000 IPIs. The number of IPIs here looks to be # of tasks
> waking up, and perhaps more than that, as there could be multiple
> instances that try to wake up the same task.
Yeah. In mainline, wakeup via IPI is disabled within a socket, because
it's too much of a performance hit for high frequency switchers. (It
seems we're limited by the max rate at which we can IPI)
-Mike
next prev parent reply other threads:[~2012-12-11 7:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-07 23:56 [RFC][PATCH RT 0/4] sched/rt: Lower rq lock contention latencies on many CPU boxes Steven Rostedt
2012-12-07 23:56 ` [RFC][PATCH RT 1/4] sched/rt: Fix push_rt_task() to have the same checks as the caller did Steven Rostedt
2012-12-07 23:56 ` [RFC][PATCH RT 2/4] sched/rt: Try to migrate task if preempting pinned rt task Steven Rostedt
2012-12-07 23:56 ` [RFC][PATCH RT 3/4] sched/rt: Use IPI to trigger RT task push migration instead of pulling Steven Rostedt
2012-12-11 0:48 ` Frank Rowand
2012-12-11 1:15 ` Frank Rowand
2012-12-11 1:53 ` Steven Rostedt
2012-12-11 7:07 ` Mike Galbraith [this message]
2012-12-11 12:43 ` Thomas Gleixner
2012-12-11 14:02 ` Steven Rostedt
2012-12-11 14:16 ` Steven Rostedt
2012-12-11 1:41 ` Steven Rostedt
2012-12-07 23:56 ` [RFC][PATCH RT 4/4] sched/rt: Initiate a pull when the priority of a task is lowered Steven Rostedt
2012-12-10 22:59 ` [RFC][PATCH RT 0/4] sched/rt: Lower rq lock contention latencies on many CPU boxes Clark Williams
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=1355209663.7057.77.camel@marge.simpson.net \
--to=bitbucket@online.de \
--cc=C.Emde@osadl.org \
--cc=clark.williams@gmail.com \
--cc=frank.rowand@am.sony.com \
--cc=jkacur@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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.