From: Peter Zijlstra <peterz@infradead.org>
To: paulmck@linux.vnet.ibm.com
Cc: Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
linux-rt-users <linux-rt-users@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>, Carsten Emde <ce@ceag.ch>,
Clark Williams <williams@redhat.com>,
Kumar Gala <galak@gate.crashing.org>,
Ralf Baechle <ralf@linux-mips.org>, rostedt <rostedt@goodmis.org>
Subject: Re: On migrate_disable() and latencies
Date: Mon, 25 Jul 2011 10:30:53 +0200 [thread overview]
Message-ID: <1311582653.2617.49.camel@laptop> (raw)
In-Reply-To: <20110723003934.GP2382@linux.vnet.ibm.com>
On Fri, 2011-07-22 at 17:39 -0700, Paul E. McKenney wrote:
> > Therefore the worst case latency is in the order of
> > max-migrate-disable-period * nr-cpus.
>
> OK, but wouldn't that be the latency as seen be the lowest-priority
> task?
It would indeed, the utility loss is added to the preemption cost of the
lower priority tasks.
> Or are migrate-disable tasks given preferential treatment?
> If not, a prio-99 task would get the same latency either way, right?
Right.
> Migration-disable can magnify the latency seen by low-priority tasks, if
> I understand correctly. If you disabled preemption, when a low-priority
> task became runnable, it would find an idle CPU. But with migration
> disable, the lowest-priority task might enter a migration-disable region,
> then be preempted by a marginally higher-priority task that also enters
> a migration-diable region, and is also preempted, and so on. The
> lowest-priority task cannot run on the current CPU because of all
> the higher-priority tasks, and cannot migrate due to being in a
> migration-disable section.
Exactly so.
> In other words, as is often the case, better worst-case service to
> the high-priority tasks can multiply the latency seen by the
> low-priority tasks.
>
> So is the topic to quantify this?
I suppose it is indeed. Even for the SoftRT case we need to make sure
the total utilization loss is indeed acceptable.
> If so, my take is that the latency
> to the highest-priority task decreases by an amount roughly equal to
> the duration of the longest preempt_disable() region that turned into a
> migration-disable region, while that to the lowest-priority task increases
> by N-1 times the CPU overhead of the longest migration-disable region,
> plus context switches. (Yes, this is a very crude rule-of-thumb model.
> A real model would have much higher mathematics and might use a more
> detailed understanding of the workload.)
>
> Or am I misunderstanding how all this works?
No, I think you're gettin' it.
My main worry with all this is that we have these insane long !preempt
regions in mainline that are now !migrate regions, and thus per all the
above we could be looking at a substantial utilization loss.
Alternatively we could all be missing something far more horrid, but
that might just be my paranoia talking.
next prev parent reply other threads:[~2011-07-25 8:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-22 10:19 On migrate_disable() and latencies Peter Zijlstra
2011-07-22 10:49 ` Peter Zijlstra
2011-07-22 14:57 ` Peter Zijlstra
2011-07-22 17:45 ` Nicholas Mc Guire
2011-07-25 8:21 ` Peter Zijlstra
2011-07-23 0:39 ` Paul E. McKenney
2011-07-25 8:30 ` Peter Zijlstra [this message]
2011-07-25 21:17 ` Paul E. McKenney
2011-07-27 11:13 ` Peter Zijlstra
2011-07-27 18:30 ` Paul E. McKenney
2011-07-28 5:50 ` Yong Zhang
2011-07-28 7:01 ` Thomas Gleixner
2011-07-28 7:10 ` Yong Zhang
2011-07-28 7:54 ` Nicholas Mc Guire
2011-07-28 12:05 ` Paul E. McKenney
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=1311582653.2617.49.camel@laptop \
--to=peterz@infradead.org \
--cc=ce@ceag.ch \
--cc=galak@gate.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--cc=ralf@linux-mips.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=williams@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).