[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110623124310.GA15430@elte.hu>
Date: Thu, 23 Jun 2011 14:43:10 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
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>,
Pavel Emelyanov <xemul@...nvz.org>
Subject: Re: [patch 00/16] CFS Bandwidth Control v7
* Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> On Wed, 2011-06-22 at 19:05 +0900, Hidetoshi Seto wrote:
>
> > I'll continue my test/benchmark on this v7 for a while. Though I
> > believe no more bug is there, I'll let you know if there is
> > something.
>
> Would that testing include performance of a kernel without these
> patches vs one with these patches in a configuration where the new
> feature is compiled in but not used?
>
> It does add a number of if (!cfs_rq->runtime_enabled) return
> branches all over the place, some possibly inside a function call
> (depending on what the auto-inliner does). So while the impact
> should be minimal, it would be very good to test it is indeed so.
Yeah, doing such performance tests is absolutely required. Branches
and instructions impact should be measured as well, beyond the cycles
impact.
The changelog of this recent commit:
c8b281161dfa: sched: Increase SCHED_LOAD_SCALE resolution
gives an example of how to do such measurements.
Thanks,
Ingo
--
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