[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 07 Jul 2011 19:08:57 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Andi Kleen <andi@...stfloor.org>
Cc: Ingo Molnar <mingo@...e.hu>, Paul Turner <pjt@...gle.com>,
linux-kernel@...r.kernel.org,
Bharata B Rao <bharata@...ux.vnet.ibm.com>,
Dhaval Giani <dhaval.giani@...il.com>,
Balbir Singh <balbir@...ux.vnet.ibm.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>,
Pavel Emelyanov <xemul@...nvz.org>,
Hu Tao <hutao@...fujitsu.com>
Subject: Re: [patch 00/17] CFS Bandwidth Control v7.1
On Thu, 2011-07-07 at 09:52 -0700, Andi Kleen wrote:
> Peter Zijlstra <a.p.zijlstra@...llo.nl> writes:
> >
> > +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
>
> You would need a *LOT* of calls to make up for 9%.
>
> Maybe it's something else? Some profiling first before optimization
> is probably a good idea.
This is the 1.5% case where the feature is compiled in but not used.
--
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