linux-kernel - Re: [PATCH V2 1/1][cleanup] memcg: renaming of mem variable to memcg

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] [day] [month] [year] [list]

Message-ID: <4E4E00E3.7080306@linux.vnet.ibm.com>
Date:	Fri, 19 Aug 2011 11:51:23 +0530
From:	Raghavendra K T <raghukt@...ux.vnet.ibm.com>
To:	Michal Hocko <mhocko@...e.cz>
CC:	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>,
	Arend van Spriel <arend@...adcom.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	"David S. Miller" <davem@...emloft.net>,
	"nishimura@....nes.nec.co.jp" <nishimura@....nes.nec.co.jp>,
	Balbir Singh <bsingharora@...il.com>,
	"John W. Linville" <linville@...driver.com>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ying Han <yinghan@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	"Nikunj A. Dadhania" <nikunj@...ux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Ciju Rajan K <ciju@...ux.vnet.ibm.com>,
	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>
Subject: Re: [PATCH V2 1/1][cleanup] memcg: renaming of mem variable to memcg

On 08/17/2011 06:13 PM, Michal Hocko wrote:
> Sorry for late reply
>
> On Fri 12-08-11 12:36:23, Raghavendra K T wrote:
>>   The memcg code sometimes uses "struct mem_cgroup *mem" and sometimes uses
>>   "struct mem_cgroup *memcg". This patch renames all mem variables to memcg in
>>   source file.
>>
>> Testing : Compile tested with following configurations.
>> 1) make defconfig ARCH=i386 + CONFIG_CGROUP_MEM_RES_CTLR=y
>> CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y
>>
>> Binary size Before patch
>> ========================
>>     text	   data	    bss	    dec	    hex	filename
>> 8911169	 520464	1884160	11315793	 acaa51	vmlinux
>>
>> Binary Size After patch
>> =======================
>>     text	   data	    bss	    dec	    hex	filename
>> 8911169	 520464	1884160	11315793	 acaa51	vmlinux
>
> It would be much nicer to see unchanged md5sum. I am not sure how much
> possible is this with current gcc or whether special command line
> parameters have to be used (at least !CONFIG_DEBUG_INFO* is necessary)
> but simple variable rename shouldn't be binary visible.
> I guess that a similar approach was used during 32b and 64b x86
> unification.
>
I agree,  I could get same MD5 sum only in N N N config case (3rd config).
  I am not sure whether we can get same Md5 after lines have been split.
Here is what I tried: static KBUILD_BUILD_TIMESTAMP 
KBUILD_BUILD_VERSION, initramfs source. strip vmlinux. (could not 
disable CONFIG_BUG).
I referred to 32nb 64b unification also, did not get much insight from 
there on same MD5.

>>
>> 2) make defconfig ARCH=i386 + CONFIG_CGROUP_MEM_RES_CTLR=y
>> CONFIG_CGROUP_MEM_RES_CTLR_SWAP=n CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=n
>
> I would assume the same testing results as above
Yes
8908671	 519808	1884160	11312639	 ac9dff	vmlinux
>
>>
>> 3) make defconfig ARCH=i386  CONFIG_CGROUP_MEM_RES_CTLR=n
>> CONFIG_CGROUP_MEM_RES_CTLR_SWAP=n CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=n
>
> ditto.

8878794	 517632	1880064	11276490	 ac10ca	vmlinux before and after
>
>>
>> Other sanity check:
>> Bootable configuration on x86 (T60p)  with  CONFIG_CGROUP_MEM_RES_CTLR=y
>> CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y
>> is tesed with basic mounting of memcgroup, creation of child and parallel fault.
>> mkdir -p /cgroup
>> mount -t cgroup none /cgroup -o memory
>> mkdir /cgroup/0
>> echo $$>  /cgroup/0/tasks
>> time ./parallel_fault 2 100000 32
>>
>> real	0m0.025s
>> user	0m0.001s
>> sys	0m0.033s
>
> This looks like a random test. I wouldn't add it to the changelog.
Agree.

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