Messages in this thread | | | From | Paul Turner <> | Date | Fri, 8 Jul 2011 00:39:15 -0700 | Subject | Re: [patch 00/17] CFS Bandwidth Control v7.1 |
| |
On Thu, Jul 7, 2011 at 7:38 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > On Thu, 2011-07-07 at 13:23 +0200, Ingo Molnar wrote: >> >> The +1.5% increase in vanilla kernel context switching performance is >> unfortunate - where does that overhead come from? > > Looking at the asm output, I think its partly because things like: > > @@ -602,6 +618,8 @@ static void update_curr(struct cfs_rq *c > cpuacct_charge(curtask, delta_exec); > account_group_exec_runtime(curtask, delta_exec); > } > + > + account_cfs_rq_runtime(cfs_rq, delta_exec); > } > > > +static void account_cfs_rq_runtime(struct cfs_rq *cfs_rq, > + unsigned long delta_exec) > +{ > + if (!cfs_rq->runtime_enabled) > + return; > + > + cfs_rq->runtime_remaining -= delta_exec; > + if (cfs_rq->runtime_remaining > 0) > + return; > + > + assign_cfs_rq_runtime(cfs_rq); > +} > > generate a call, only to then take the first branch out, marking that > function __always_inline would cure the call problem.
Indeed! I looked at this today, fixing this inlining recovers ~50% of the cost; however, my numbers are not directly comparable to Hu's (~2% originally, improving to ~1%).
> Going beyond that > would be using static_branch() to track if there is any bandwidth > tracking required at all. >
I spent some time examining this option as well. Our toolchain apparently is stuck on gcc-4.4 which left me scratching my head at the supposed jump label assembly being omitted until I realized CC_HAS_ASM_GOTO was missing. I will roll this up also and benchmark tomorrow. -- 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/
| |