From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753481Ab2A2Qdq (ORCPT ); Sun, 29 Jan 2012 11:33:46 -0500 Received: from mx2.mail.elte.hu ([157.181.151.9]:45098 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753030Ab2A2Qdp (ORCPT ); Sun, 29 Jan 2012 11:33:45 -0500 Date: Sun, 29 Jan 2012 17:33:28 +0100 From: Ingo Molnar To: Michael Wang Cc: Cong Wang , Peter Zijlstra , Xiaotian Feng , LKML Subject: Re: [PATCH v2] sched: Accelerate "pick_next_entity" under special condition Message-ID: <20120129163328.GC23408@elte.hu> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F24E804.5090808@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=AWL,BAYES_00 autolearn=no SpamAssassin version=3.3.1 -2.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 AWL AWL: From: address is in the auto white-list Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * 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