lkml.org 
[lkml]   [2011]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2011-07-10 20:15    [from the cache]
©2003-2011 Jasper Spaans