From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752215Ab1HSGVj (ORCPT ); Fri, 19 Aug 2011 02:21:39 -0400 Received: from e28smtp04.in.ibm.com ([122.248.162.4]:56890 "EHLO e28smtp04.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750746Ab1HSGVi (ORCPT ); Fri, 19 Aug 2011 02:21:38 -0400 Message-ID: <4E4E00E3.7080306@linux.vnet.ibm.com> Date: Fri, 19 Aug 2011 11:51:23 +0530 From: Raghavendra K T User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Michal Hocko CC: Raghavendra K T , Arend van Spriel , Greg Kroah-Hartman , "David S. Miller" , "nishimura@mxp.nes.nec.co.jp" , Balbir Singh , "John W. Linville" , Mauro Carvalho Chehab , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Ying Han , Andrew Morton , KAMEZAWA Hiroyuki , "Nikunj A. Dadhania" , Srivatsa Vaddagiri , Ciju Rajan K , Kamalesh Babulal Subject: Re: [PATCH V2 1/1][cleanup] memcg: renaming of mem variable to memcg References: <20110812070623.28939.4733.sendpatchset@oc5400248562.ibm.com> <20110817124339.GA10245@tiehlicka.suse.cz> In-Reply-To: <20110817124339.GA10245@tiehlicka.suse.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.