Re: [RFT][patch 17/18] sched: use jump labels to reduce overhead when bandwidth control is inactive

[Jason Baron <jbaron@redhat.com>]

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/