From: Chen Gang <chengang@emindsoft.com.cn>
To: Michal Hocko <mhocko@kernel.org>
Cc: Minchan Kim <minchan@kernel.org>,
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 <gang.chen.5i5j@gmail.com>
Subject: Re: [PATCH] mm: migrate: Use bool instead of int for the return value of PageMovable
Date: Sun, 17 Jul 2016 08:51:11 +0800 [thread overview]
Message-ID: <578AD67F.9030905@emindsoft.com.cn> (raw)
In-Reply-To: <20160713075346.GC28723@dhcp22.suse.cz>
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 (e??a??)
Managing Natural Environments is the Duty of Human Beings.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-07-17 0:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-09 15:55 chengang
2016-07-11 0:26 ` Minchan Kim
2016-07-11 19:47 ` Chen Gang
2016-07-12 7:15 ` Vlastimil Babka
2016-07-12 16:42 ` Chen Gang
2016-07-12 7:48 ` Michal Hocko
2016-07-12 16:50 ` Chen Gang
2016-07-13 7:53 ` Michal Hocko
2016-07-17 0:51 ` Chen Gang [this message]
2016-07-13 14:26 ` 回复:[PATCH] " 陈刚
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=578AD67F.9030905@emindsoft.com.cn \
--to=chengang@emindsoft.com.cn \
--cc=akpm@linux-foundation.org \
--cc=gang.chen.5i5j@gmail.com \
--cc=gi-oh.kim@profitbricks.com \
--cc=hillf.zj@alibaba-inc.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=minchan@kernel.org \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox