linux-kernel - Re: [RFC][PATCH 0/3] impelemnt cgroup_(subsys)

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: <4ECCCBDA.5060604@parallels.com>
Date:	Wed, 23 Nov 2011 08:32:58 -0200
From:	Glauber Costa <glommer@...allels.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
CC:	<cgroups@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Tejun Heo <tj@...nel.org>,
	"lizf@...fujitsu.com" <lizf@...fujitsu.com>,
	"hannes@...xchg.org" <hannes@...xchg.org>,
	Michal Hocko <mhocko@...e.cz>,
	"bsingharora@...il.com" <bsingharora@...il.com>
Subject: Re: [RFC][PATCH 0/3] impelemnt cgroup_(subsys)_disabled in generic.

On 11/23/2011 06:28 AM, KAMEZAWA Hiroyuki wrote:
>
> Now, memory cgroup has 'mem_cgroup_disabled()' in memcontrol.h
>
> I made a brief trial to use static_branch() for that function. At doing that,
> I thought it will be better to implement generic cgroup functions rather
> than having memory cgroup's its own one.
>
> This series consists of 3 patches
> 1 .... implement cgroup_xxxx_disabled() in generic.
> 2 .... use jump_label for cgroup_xxxx_disabled()
> 3 .... remove mem_cgroup_disabled() in memcontrol.c
>
> And I post this series for getting review/comments.
> I'm not sure patches for using jump_label is worth to be merged.
>
> I did a test to run a loop
> 	while(-) {
> 		mmap(1M)
> 		touch all pages
> 		munmap()
> 	}
>
> and measured performance score in ROOT cgroup. Here,
>
> (Before patch)
>     182,932,842,128 cycles                    #    0.000 GHz                     [33.33%]
>     192,711,643,877 instructions              #    1.05  insns per cycle         [49.99%]
>         761,483,416 cache-references                                             [49.98%]
>             159,908 cache-misses              #    0.021 % of all cache refs     [50.00%]
>      33,253,084,874 branches                                                     [33.34%]
>         109,796,792 branch-misses             #    0.33% of all branches         [33.34%]
>
>        58.289265709 seconds time elapsed
>
> (After patch)
>   Performance counter stats for './malloc 1':
>
>     183,068,407,487 cycles                    #    0.000 GHz                     [33.33%]
>     191,834,248,678 instructions              #    1.05  insns per cycle         [50.00%]
>         798,635,028 cache-references                                             [49.98%]
>              95,562 cache-misses              #    0.012 % of all cache refs     [50.00%]
>      32,755,318,286 branches                                                     [33.34%]
>          77,774,624 branch-misses             #    0.24% of all branches         [33.34%]
>
>        58.332356996 seconds time elapsed
>
> There is no differece in 'time' ;)
> But I got an impression that 'branch' score gets better in several tests.
>

branch and cache misses are a lot smaller as well. I think this is a win.

--
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/