[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110805182835.GE2522@redhat.com>
Date: Fri, 5 Aug 2011 14:28:35 -0400
From: Jason Baron <jbaron@...hat.com>
To: Paul Turner <pjt@...gle.com>
Cc: linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Bharata B Rao <bharata@...ux.vnet.ibm.com>,
Dhaval Giani <dhaval.giani@...il.com>,
Balbir Singh <bsingharora@...il.com>,
Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
Srivatsa Vaddagiri <vatsa@...ibm.com>,
Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
Ingo Molnar <mingo@...e.hu>,
Pavel Emelyanov <xemul@...nvz.org>, rth@...hat.com,
rostedt@...dmis.org
Subject: Re: [RFT][patch 17/18] sched: use jump labels to reduce overhead
when bandwidth control is inactive
On Thu, Aug 04, 2011 at 08:55:08PM -0700, Paul Turner wrote:
> > --- a/kernel/Makefile
> > +++ b/kernel/Makefile
> > @@ -10,7 +10,7 @@ obj-y = sched.o fork.o exec_domain.o panic.o printk.o \
> > kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \
> > hrtimer.o rwsem.o nsproxy.o srcu.o semaphore.o \
> > notifier.o ksysfs.o pm_qos_params.o sched_clock.o cred.o \
> > - async.o range.o jump_label.o
> > + async.o range.o
> > obj-y += groups.o
> >
> > ifdef CONFIG_FUNCTION_TRACER
> > @@ -107,6 +107,7 @@ obj-$(CONFIG_PERF_EVENTS) += events/
> > obj-$(CONFIG_USER_RETURN_NOTIFIER) += user-return-notifier.o
> > obj-$(CONFIG_PADATA) += padata.o
> > obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
> > +obj-$(CONFIG_JUMP_LABEL) += jump_label.o
> >
> > ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y)
> > # According to Alan Modra <alan@...uxcare.com.au>, the -fno-omit-frame-pointer is
> >
>
> Tested-by: Paul Turner <pjt@...gle.com>
>
> Let me know if you need any result tables for the actual commit msg.
Hi Paul,
Thanks for taking the time test this :) I'll post the patch shortly
with my own testing results. Hopefully, it can still be considered for
3.1 b/c of the non-invasive nature of the patch...
> Same goes for making CONFIG_JUMP_LABEL equivalent to default in
> CC_HAS_ASM_GOTO case (at least on x86 anyway).
>
I originally had CONFIG_JUMP_LABEL implicitly turned on, but we ran into
a 32-bit compiler issue that was causing random, nasty crashes. That
issue has since been resolved in gcc, but we might need to update the
have CC_HAS_ASM_GOTO check to deal with that case better. Currently,
we're using the '-maccumulate-outgoing-args' gcc option to work around
the issue for 32 bit x86 (see: arch/x86/Makefile_32.cpu).
With the jump label interface somewhat stabilizing (I say somewhat, b/c Peter
brought up a good use case in the scheduler that it currently doesn't address,
but which we should be able to support without too much churn) and these testing
results, I think it might make sense to consider turning it on by default for
3.2. thoughts?
Thanks,
-Jason
>
> >
> > I've tested the patch using a single 'static_branch()' in the getppid() path,
> > and basically running tight loops of calls to getppid(). Before, the
> > patch, I was seeing results similar to what you reported, after the
> > patch, things improved for all metrics. Here are my results for the
> > branch disabled case:
> >
> > With jump labels turned on (CONFIG_JUMP_LABEL), branch disabled:
> >
> > Performance counter stats for 'bash -c /tmp/timing;true' (50 runs):
> >
> > 3,969,510,217 instructions # 0.864 IPC ( +-0.000% )
> > 4,592,334,954 cycles ( +- 0.046% )
> > 751,634,470 branches ( +- 0.000% )
> >
> > 1.722635797 seconds time elapsed ( +- 0.046% )
> >
> > Jump labels turned off (CONFIG_JUMP_LABEL not set), branch disabled:
> >
> > Performance counter stats for 'bash -c /tmp/timing;true' (50 runs):
> >
> > 4,009,611,846 instructions # 0.867 IPC ( +-0.000% )
> > 4,622,210,580 cycles ( +- 0.012% )
> > 771,662,904 branches ( +- 0.000% )
> >
> > 1.734341454 seconds time elapsed ( +- 0.022% )
> >
> >
> > So all of the measured metrics improved in the jump labels case b/w
> > 0.5% - 2.5%.
> >
> > I'm curious to see what you find with this patch.
> >
> > Thanks,
> >
> > -Jason
> >
> >
> >
> --
> 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/
--
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