From: Steven Rostedt <srostedt@redhat.com>
To: Chris Mason <chris.mason@oracle.com>
Cc: "Ma, Chinang" <chinang.ma@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <matthew@wil.cx>,
"Wilcox, Matthew R" <matthew.r.wilcox@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Tripathi, Sharad C" <sharad.c.tripathi@intel.com>,
"arjan@linux.intel.com" <arjan@linux.intel.com>,
"Kleen, Andi" <andi.kleen@intel.com>,
"Siddha, Suresh B" <suresh.b.siddha@intel.com>,
"Chilukuri, Harita" <harita.chilukuri@intel.com>,
"Styner, Douglas W" <douglas.w.styner@intel.com>,
"Wang, Peter Xihong" <peter.xihong.wang@intel.com>,
"Nueckel, Hubert" <hubert.nueckel@intel.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
Andrew Vasquez <andrew.vasquez@qlogic.com>,
Anirban Chakraborty <anirban.chakraborty@qlogic.com>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>
Subject: RE: Mainline kernel OLTP performance update
Date: Mon, 19 Jan 2009 14:07:35 -0500 [thread overview]
Message-ID: <1232392055.25783.9.camel@localhost.localdomain> (raw)
In-Reply-To: <1232391305.6521.146.camel@think.oraclecorp.com>
On Mon, 2009-01-19 at 13:55 -0500, Chris Mason wrote:
> I wasn't actually looking at the cost of the checks, even though they do
> look higher (if they are using CONFIG_CPUMASK_OFFSTACK anyway).
>
> The 2.6.24 code would trigger a rescheduling interrupt only when the
> prio of the inbound task was higher than the running task.
>
> This workload has a large number of equal priority rt tasks that are not
> bound to a single CPU, and so I think it should trigger more
> preempts/reschedules with the today's check_preempt_equal_prio().
Ah yeah. This is one of the things that shows RT being more "responsive"
but less on performance. An RT task wants to run ASAP even if that means
there's a chance of more interrupts and higher cache misses.
The old way would be much faster in general through put, but I measured
RT tasks taking up to tens of milliseconds to get scheduled. This is
unacceptable for an RT task.
-- Steve
WARNING: multiple messages have this Message-ID (diff)
From: Steven Rostedt <srostedt@redhat.com>
To: Chris Mason <chris.mason@oracle.com>
Cc: "Ma, Chinang" <chinang.ma@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <matthew@wil.cx>,
"Wilcox, Matthew R" <matthew.r.wilcox@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Tripathi, Sharad C" <sharad.c.tripathi@intel.com>,
"arjan@linux.intel.com" <arjan@linux.intel.com>,
"Kleen, Andi" <andi.kleen@intel.com>,
"Siddha, Suresh B" <suresh.b.siddha@intel.com>,
"Chilukuri, Harita" <harita.chilukuri@intel.com>,
"Styner, Douglas W" <douglas.w.styner@intel.com>,
"Wang, Peter Xihong" <peter.xihong.wang@intel.com>,
"Nueckel, Hubert" <hubert.nueckel@intel.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
Andrew Vasquez <andrew.vasquez@qlogic.com>,
Anirban Chakraborty <anirban.chakraborty@qlogic.com>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Gregory Haskins <ghaskins@novell.com>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: RE: Mainline kernel OLTP performance update
Date: Mon, 19 Jan 2009 14:07:35 -0500 [thread overview]
Message-ID: <1232392055.25783.9.camel@localhost.localdomain> (raw)
In-Reply-To: <1232391305.6521.146.camel@think.oraclecorp.com>
On Mon, 2009-01-19 at 13:55 -0500, Chris Mason wrote:
> I wasn't actually looking at the cost of the checks, even though they do
> look higher (if they are using CONFIG_CPUMASK_OFFSTACK anyway).
>
> The 2.6.24 code would trigger a rescheduling interrupt only when the
> prio of the inbound task was higher than the running task.
>
> This workload has a large number of equal priority rt tasks that are not
> bound to a single CPU, and so I think it should trigger more
> preempts/reschedules with the today's check_preempt_equal_prio().
Ah yeah. This is one of the things that shows RT being more "responsive"
but less on performance. An RT task wants to run ASAP even if that means
there's a chance of more interrupts and higher cache misses.
The old way would be much faster in general through put, but I measured
RT tasks taking up to tens of milliseconds to get scheduled. This is
unacceptable for an RT task.
-- Steve
next prev parent reply other threads:[~2009-01-19 19:07 UTC|newest]
Thread overview: 134+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 21:10 Mainline kernel OLTP performance update Ma, Chinang
2009-01-13 22:44 ` Wilcox, Matthew R
2009-01-15 0:35 ` Andrew Morton
2009-01-15 1:21 ` Matthew Wilcox
2009-01-15 2:04 ` Andrew Morton
2009-01-15 2:27 ` Steven Rostedt
2009-01-15 7:11 ` Ma, Chinang
2009-01-15 7:11 ` Ma, Chinang
2009-01-19 18:04 ` Chris Mason
2009-01-19 18:04 ` Chris Mason
2009-01-19 18:37 ` Steven Rostedt
2009-01-19 18:37 ` Steven Rostedt
2009-01-19 18:55 ` Chris Mason
2009-01-19 18:55 ` Chris Mason
2009-01-19 19:07 ` Steven Rostedt [this message]
2009-01-19 19:07 ` Steven Rostedt
2009-01-19 23:40 ` Ingo Molnar
2009-01-19 23:40 ` Ingo Molnar
2009-01-15 2:39 ` Andi Kleen
2009-01-15 2:47 ` Matthew Wilcox
2009-01-15 3:36 ` Andi Kleen
2009-01-20 13:27 ` Jens Axboe
[not found] ` <588992150B702C48B3312184F1B810AD03A497632C@azsmsx501.amr.corp.intel.com>
2009-01-22 11:29 ` Jens Axboe
[not found] ` <588992150B702C48B3312184F1B810AD03A4F59632@azsmsx501.amr.corp.intel.com>
2009-01-27 8:28 ` Jens Axboe
2009-01-15 7:24 ` Nick Piggin
2009-01-15 9:46 ` Pekka Enberg
2009-01-15 13:52 ` Matthew Wilcox
2009-01-15 14:42 ` Pekka Enberg
2009-01-16 10:16 ` Pekka Enberg
2009-01-16 10:21 ` Nick Piggin
2009-01-16 10:31 ` Pekka Enberg
2009-01-16 10:42 ` Nick Piggin
2009-01-16 10:55 ` Pekka Enberg
2009-01-19 7:13 ` Nick Piggin
2009-01-19 8:05 ` Pekka Enberg
2009-01-19 8:33 ` Nick Piggin
2009-01-19 8:42 ` Nick Piggin
2009-01-19 8:47 ` Pekka Enberg
2009-01-19 8:57 ` Nick Piggin
2009-01-19 9:48 ` Pekka Enberg
2009-01-19 10:03 ` Nick Piggin
2009-01-16 20:59 ` Christoph Lameter
2009-01-16 0:27 ` Andrew Morton
2009-01-16 4:03 ` Nick Piggin
2009-01-16 4:12 ` Andrew Morton
2009-01-16 6:46 ` Nick Piggin
2009-01-16 6:55 ` Matthew Wilcox
2009-01-16 7:06 ` Nick Piggin
2009-01-16 7:53 ` Zhang, Yanmin
2009-01-16 10:20 ` Andi Kleen
2009-01-20 5:16 ` Zhang, Yanmin
2009-01-21 23:58 ` Christoph Lameter
2009-01-22 8:36 ` Zhang, Yanmin
2009-01-22 9:15 ` Pekka Enberg
2009-01-22 9:15 ` Pekka Enberg
2009-01-22 9:28 ` Zhang, Yanmin
2009-01-22 9:47 ` Pekka Enberg
2009-01-23 3:02 ` Zhang, Yanmin
2009-01-23 3:02 ` Zhang, Yanmin
2009-01-23 6:52 ` Pekka Enberg
2009-01-23 6:52 ` Pekka Enberg
2009-01-23 8:06 ` Pekka Enberg
2009-01-23 8:30 ` Zhang, Yanmin
2009-01-23 8:40 ` Pekka Enberg
2009-01-23 9:46 ` Pekka Enberg
2009-01-23 15:22 ` Christoph Lameter
2009-01-23 15:31 ` Pekka Enberg
2009-01-23 15:55 ` Christoph Lameter
2009-01-23 16:01 ` Pekka Enberg
2009-01-24 2:55 ` Zhang, Yanmin
2009-01-24 7:36 ` Pekka Enberg
2009-02-12 5:22 ` Zhang, Yanmin
2009-02-12 5:47 ` Zhang, Yanmin
2009-02-12 5:47 ` Zhang, Yanmin
2009-02-12 15:25 ` Christoph Lameter
2009-02-12 16:07 ` Pekka Enberg
2009-02-12 16:03 ` Pekka Enberg
2009-01-26 17:36 ` Christoph Lameter
2009-02-01 2:52 ` Zhang, Yanmin
2009-01-23 8:33 ` Nick Piggin
2009-01-23 9:02 ` Zhang, Yanmin
2009-01-23 18:40 ` care and feeding of netperf (Re: Mainline kernel OLTP performance update) Rick Jones
2009-01-23 18:51 ` Grant Grundler
2009-01-23 18:51 ` Grant Grundler
2009-01-24 3:03 ` Zhang, Yanmin
2009-01-26 18:26 ` Rick Jones
2009-01-16 7:00 ` Mainline kernel OLTP performance update Andrew Morton
2009-01-16 7:25 ` Nick Piggin
2009-01-16 8:59 ` Nick Piggin
2009-01-16 18:11 ` Rick Jones
2009-01-19 7:43 ` Nick Piggin
2009-01-19 22:19 ` Rick Jones
2009-01-15 14:12 ` James Bottomley
2009-01-15 17:44 ` Andrew Morton
2009-01-15 18:00 ` Matthew Wilcox
2009-01-15 18:14 ` Steven Rostedt
2009-01-15 18:44 ` Gregory Haskins
2009-01-15 18:46 ` Wilcox, Matthew R
2009-01-15 18:46 ` Wilcox, Matthew R
2009-01-15 19:44 ` Ma, Chinang
2009-01-16 18:14 ` Gregory Haskins
2009-01-16 19:09 ` Steven Rostedt
2009-01-20 12:45 ` Gregory Haskins
2009-01-15 19:28 ` Ma, Chinang
2009-01-15 16:48 ` Ma, Chinang
-- strict thread matches above, loose matches on Subject: below --
2010-01-25 18:26 Ma, Chinang
2009-05-04 15:54 Styner, Douglas W
2009-05-06 6:29 ` Anirban Chakraborty
2009-05-06 15:53 ` Wilcox, Matthew R
2009-05-06 18:05 ` Styner, Douglas W
2009-05-06 18:12 ` Wilcox, Matthew R
2009-05-06 18:24 ` Anirban Chakraborty
2009-05-06 19:25 ` Wilcox, Matthew R
2009-05-06 18:19 ` Styner, Douglas W
2009-04-28 17:22 Styner, Douglas W
2009-04-28 17:08 Styner, Douglas W
2009-04-29 7:29 ` Andrew Morton
2009-04-29 8:28 ` Andi Kleen
2009-04-29 16:00 ` Styner, Douglas W
2009-04-29 16:06 ` Wilcox, Matthew R
2009-04-29 16:19 ` Andi Kleen
2009-04-29 15:48 ` Styner, Douglas W
2009-04-29 16:07 ` Andrew Morton
2009-04-29 16:25 ` Peter Zijlstra
2009-04-29 17:46 ` Chris Mason
2009-04-29 18:06 ` Pallipadi, Venkatesh
2009-04-29 18:25 ` Styner, Douglas W
2009-04-29 17:52 ` Styner, Douglas W
2009-04-23 16:49 Styner, Douglas W
2009-04-27 7:02 ` Andi Kleen
2009-04-28 16:57 ` Chuck Ebbert
2009-04-28 17:15 ` James Bottomley
2009-04-28 17:17 ` Styner, Douglas W
2009-01-12 18:30 Ma, Chinang
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=1232392055.25783.9.camel@localhost.localdomain \
--to=srostedt@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andi.kleen@intel.com \
--cc=andrew.vasquez@qlogic.com \
--cc=anirban.chakraborty@qlogic.com \
--cc=arjan@linux.intel.com \
--cc=chinang.ma@intel.com \
--cc=chris.mason@oracle.com \
--cc=douglas.w.styner@intel.com \
--cc=harita.chilukuri@intel.com \
--cc=hubert.nueckel@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew.r.wilcox@intel.com \
--cc=matthew@wil.cx \
--cc=mingo@redhat.com \
--cc=peter.xihong.wang@intel.com \
--cc=peterz@infradead.org \
--cc=sharad.c.tripathi@intel.com \
--cc=suresh.b.siddha@intel.com \
--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.