Messages in this thread | | | Date | Fri, 5 Aug 2011 14:28:35 -0400 | From | Jason Baron <> | 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@linuxcare.com.au>, the -fno-omit-frame-pointer is > > > > Tested-by: Paul Turner <pjt@google.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@vger.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |