Messages in this thread | | | Subject | RE: Mainline kernel OLTP performance update | From | Chris Mason <> | Date | Mon, 19 Jan 2009 13:55:05 -0500 |
| |
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
| |