Messages in this thread |  | | Date | Sun, 10 Jul 2011 20:12:05 +0200 | From | Ingo Molnar <> | Subject | Re: [patch 00/17] CFS Bandwidth Control v7.1 |
| |
* Paul Turner <pjt@google.com> wrote:
> Finally introducing jump labels when there are no constrained > groups claws back a good portion of the remaining time. > > Add jump labels: > cycles instructions > branches > ---------------------------------------------------------------------------------------------------- > base 893,486,206 840,904,951 160,076,980 > +unconstrained 900,477,543 (+0.78) 890,310,950 (+5.88) > 161,037,844 (+0.60) > +10000000000/1000: 921,436,697 (+3.13) 919,362,792 (+9.33) > 168,491,279 (+5.26) > +10000000000/10000: 907,214,638 (+1.54) 894,406,875 (+6.36) > 165,743,207 (+3.54) > +10000000000/100000: 918,094,542 (+2.75) 910,211,234 (+8.24) > 167,841,828 (+4.85) > +10000000000/1000000: 910,698,725 (+1.93) 885,385,460 (+5.29) > 166,406,742 (+3.95)
That looks pretty promising!
The +5% instruction count still looks a tad high to me: if there are about 1000 instructions in this particular contex-switch critical path then 5% means +50 instructions - a 'disabled' feature sure should not use that many instructions, right?
Also, i have a testing suggestion, i'd suggest to run:
taskset 1 perf stat ...
to only measure while pinned on a single CPU. This will remove a lot of cross-CPU noise from the context switching overhead.
This is a valid way to progress because we are interested in the typical context-switch overhead on a single CPU - we know that there's no SMP cost when constraining is disabled.
Doing that should bring your measurement noise below the 0.1% range i suspect. As you are shaving off cycle after cycle i think you'll need that kind of measurement precision ...
Thanks,
Ingo
|  |