Re: [patch 00/17] CFS Bandwidth Control v7.1

[Ingo Molnar]

* Paul Turner <pjt@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/