From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751962AbcGQAuH (ORCPT ); Sat, 16 Jul 2016 20:50:07 -0400 Received: from out1134-242.mail.aliyun.com ([42.120.134.242]:62804 "EHLO out1134-242.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751809AbcGQAuE (ORCPT ); Sat, 16 Jul 2016 20:50:04 -0400 X-Greylist: delayed 303 seconds by postgrey-1.27 at vger.kernel.org; Sat, 16 Jul 2016 20:50:03 EDT X-Alimail-AntiSpam: AC=CONTINUE;BC=0.07445557|-1;FP=0|0|0|0|0|-1|-1|-1;HT=e02c03308;MF=chengang@emindsoft.com.cn;NM=1;PH=DS;RN=12;RT=12;SR=0;TI=SMTPD_----51u9Meg_1468716287; Message-ID: <578AD67F.9030905@emindsoft.com.cn> Date: Sun, 17 Jul 2016 08:51:11 +0800 From: Chen Gang User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michal Hocko CC: Minchan Kim , akpm@linux-foundation.org, vbabka@suse.cz, mgorman@techsingularity.net, gi-oh.kim@profitbricks.com, iamjoonsoo.kim@lge.com, hillf.zj@alibaba-inc.com, rientjes@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Chen Gang Subject: Re: [PATCH] mm: migrate: Use bool instead of int for the return value of PageMovable References: <1468079704-5477-1-git-send-email-chengang@emindsoft.com.cn> <20160711002605.GD31817@bbox> <5783F7DE.9020203@emindsoft.com.cn> <20160712074841.GE14586@dhcp22.suse.cz> <57851FC4.4000000@emindsoft.com.cn> <20160713075346.GC28723@dhcp22.suse.cz> In-Reply-To: <20160713075346.GC28723@dhcp22.suse.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/13/16 15:53, Michal Hocko wrote: > On Wed 13-07-16 00:50:12, Chen Gang wrote: >> >> >> On 7/12/16 15:48, Michal Hocko wrote: >>> On Tue 12-07-16 03:47:42, Chen Gang wrote: >>> [...] >>>> In our case, the 2 output size are same, but under x86_64, the insns are >>>> different. After uses bool, it uses push/pop instead of branch, for me, >>>> it should be a little better for catching. >>> >>> The code generated for bool version looks much worse. Look at the fast >>> path. Gcc tries to reuse the retq from the fast path in the bool case >>> and so it has to push rbp and rbx on the stack. >>> >>> That being said, gcc doesn't seem to generate a better code for bool so >>> I do not think this is really worth it. >>> >> >> The code below also merge 3 statements into 1 return statement, although >> for me, it is a little more readable, it will generate a little bad code. >> That is the reason why the output looks a little bad. >> >> In our case, for gcc 6.0, using bool instead of int for bool function >> will get the same output under x86_64. > > If the output is same then there is no reason to change it. > For the new version gcc, the output is same. But bool is a little more readable than int for the pure bool function. But for the current widely used gcc version (I guess, gcc-4.8 is still widely used), bool will get a little better output than int for the pure bool function. >> In our case, for gcc 4.8, using bool instead of int for bool function >> will get a little better output under x86_64. > > I had a different impression and the fast path code had more > instructions. But anyway, is there really a strong reason to change > those return values in the first place? Isn't that just a pointless code > churn? > Excuse me, maybe, I do not quite understand your meanings, but I shall try to explain as far as I can understand (welcome additional detail explanation, e.g. "return values" means c code or assembly output code). In the previous reply, I did not mention 3 things directly and clearly (about my 2 mistakes, and the comparation between gcc 6.0 and 4.8): - Mistake 1: "Use one return statement instead of several statements" is not good, the modification may be a little more readable, but it may get a little bad output code by compiler. - Mistake 2: I only notice there is more branches, but did not notice the real execution path (I guess, your "fast path" is about it). - The optimization of upstream gcc 6.0 is better than redhat gcc 4.8: in this case, gcc 6.0 will: generate the same better code for both bool and int for the pure bool function. optimize the first checking branch (no prologue) -- gcc 4.8 need mark 'likely' for it. skip the 'likely' optimization when "use 1 return statement instead of several statements" -- generation a little bad code too. All together, for me: - Only use bool instead of int for pure bool functions' return value will get a little better code - I shall send patch v2, only change bool to int for all Page_XXX, and keep all the other things no touch. Thanks. -- Chen Gang (陈刚) Managing Natural Environments is the Duty of Human Beings.