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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110710181205.GA21375@elte.hu>
Date:	Sun, 10 Jul 2011 20:12:05 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Paul Turner <pjt@...gle.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	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

* Paul Turner <pjt@...gle.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
--
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/