Message-ID: <578AD67F.9030905@emindsoft.com.cn>
Date:	Sun, 17 Jul 2016 08:51:11 +0800
From:	Chen Gang <chengang@...ndsoft.com.cn>
To:	Michal Hocko <mhocko@...nel.org>
CC:	Minchan Kim <minchan@...nel.org>, akpm@...ux-foundation.org,
	vbabka@...e.cz, mgorman@...hsingularity.net,
	gi-oh.kim@...fitbricks.com, iamjoonsoo.kim@....com,
	hillf.zj@...baba-inc.com, rientjes@...gle.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Chen Gang <gang.chen.5i5j@...il.com>
Subject: Re: [PATCH] mm: migrate: Use bool instead of int for the return value
 of PageMovable


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.

Powered by blists - more mailing lists