From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754225Ab2A3DSc (ORCPT ); Sun, 29 Jan 2012 22:18:32 -0500 Received: from e23smtp06.au.ibm.com ([202.81.31.148]:47472 "EHLO e23smtp06.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753081Ab2A3DSb (ORCPT ); Sun, 29 Jan 2012 22:18:31 -0500 Message-ID: <4F260BFE.2070503@linux.vnet.ibm.com> Date: Mon, 30 Jan 2012 11:18:22 +0800 From: Michael Wang User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Ingo Molnar CC: Cong Wang , Peter Zijlstra , Xiaotian Feng , LKML Subject: Re: [PATCH v2] sched: Accelerate "pick_next_entity" under special condition References: <4F13EFBE.1030002@linux.vnet.ibm.com> <1326707503.2442.219.camel@twins> <4F14DEAE.60702@linux.vnet.ibm.com> <4F14E54E.80904@linux.vnet.ibm.com> <1327506934.2614.87.camel@laptop> <20120126100429.GA3853@elte.hu> <4F21FC69.6040402@linux.vnet.ibm.com> <4F222B2B.6010602@gmail.com> <4F24E804.5090808@linux.vnet.ibm.com> <20120129163328.GC23408@elte.hu> In-Reply-To: <20120129163328.GC23408@elte.hu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit x-cbid: 12012917-7014-0000-0000-0000007E1A26 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/30/2012 12:33 AM, Ingo Molnar wrote: > > * Michael Wang wrote: > >> On 01/27/2012 12:42 PM, Cong Wang wrote: >> >>> On 01/27/2012 09:22 AM, Michael Wang wrote: >>>> Hi, Ingo >>>> >>>> Thanks for your reply. >>>> >>>> I have try use "ls -l" to see the size of sched.o, but after applied the >>>> patch, it is still 1636. >>>> >>>> I have not use this method before, may be I use the wrong command... >>>> >>>> But I think the new code should be similar to the old one after compile, >>>> because we still have 3 condition check here. >>>> >>>> I suppose the new sched.o will be a little bigger, because one jump >>>> command and a label need to be added. >>>> >>> >>> Try to see if `size` helps. >> >> Hi, Cong >> >> Thanks for your advise, but still, the size not changed. >> >> And also I don't know whether the size can be some kind of >> proof to confirm the performance improvement in this case... > > You could disassemble the .o file via objdump -d and run diff on > it - is there any change in the code generated by GCC? > > Thanks, > > Ingo > This tool is great :) But the sched.o under ./arch/x86/kernel/cpu/ still not change... I think I may checking the wrong file, because this patch is for fair.c. And the fair.o changed after apply the patch, the size is a little bigger, and the gcc generated code changed. But I still don't know what can we get from this result? Bigger size is caused by additional code, but these additional code will help to step over some unnecessary code under special condition, looks like some balance between size and performance... Regards, Michael Wang