[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1232391305.6521.146.camel@think.oraclecorp.com>
Date: Mon, 19 Jan 2009 13:55:05 -0500
From: Chris Mason <chris.mason@...cle.com>
To: Steven Rostedt <srostedt@...hat.com>
Cc: "Ma, Chinang" <chinang.ma@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Matthew Wilcox <matthew@....cx>,
"Wilcox, Matthew R" <matthew.r.wilcox@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Tripathi, Sharad C" <sharad.c.tripathi@...el.com>,
"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
"Kleen, Andi" <andi.kleen@...el.com>,
"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
"Chilukuri, Harita" <harita.chilukuri@...el.com>,
"Styner, Douglas W" <douglas.w.styner@...el.com>,
"Wang, Peter Xihong" <peter.xihong.wang@...el.com>,
"Nueckel, Hubert" <hubert.nueckel@...el.com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
Andrew Vasquez <andrew.vasquez@...gic.com>,
Anirban Chakraborty <anirban.chakraborty@...gic.com>,
Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Gregory Haskins <ghaskins@...ell.com>,
Rusty Russell <rusty@...tcorp.com.au>
Subject: RE: Mainline kernel OLTP performance update
On Mon, 2009-01-19 at 13:37 -0500, Steven Rostedt wrote:
> (added Rusty)
>
> On Mon, 2009-01-19 at 13:04 -0500, Chris Mason wrote:
> >
> > I think the -rt version of check_preempt_equal_prio has gotten much more
> > expensive since 2.6.24.
> >
> > I'm sure these changes were made for good reasons, and this workload may
> > not be a good reason to change it back. But, what does the patch below
> > do to performance on 2.6.29-rcX?
> >
> > -chris
> >
> > diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
> > index 954e1a8..bbe3492 100644
> > --- a/kernel/sched_rt.c
> > +++ b/kernel/sched_rt.c
> > @@ -842,6 +842,7 @@ static void check_preempt_curr_rt(struct rq *rq,
> > struct task_struct *p, int sync
> > resched_task(rq->curr);
> > return;
> > }
> > + return;
> >
> > #ifdef CONFIG_SMP
> > /*
>
> That should not cause much of a problem if the scheduling task is not
> pinned to an CPU. But!!!!!
>
> A recent change makes it expensive:
> + if (!alloc_cpumask_var(&mask, GFP_ATOMIC))
> return;
> check_preempt_equal_prio is in a scheduling hot path!!!!!
>
> WTF are we allocating there for?
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().
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists