From: yuankuiz@codeaurora.org
To: Tejun Heo <tj@kernel.org>
Cc: cgroups@vger.kernel.org, lizefan@huawei.com, hannes@cmpxchg.org,
linux-kernel@vger.kernel.org, pkondeti@codeaurora.org,
cgroups-owner@vger.kernel.org
Subject: Re: [PATCH]cgroup: __cpuset_node_allowed return bool
Date: Mon, 26 Mar 2018 22:20:43 +0800 [thread overview]
Message-ID: <3540bc7869927f54c409b697c743938a@codeaurora.org> (raw)
In-Reply-To: <20180326141212.GI2149215@devbig577.frc2.facebook.com>
Hi Tejun,
inline.
On 2018-03-26 10:12 PM, Tejun Heo wrote:
> Hello, John.
>
> On Sat, Mar 24, 2018 at 01:05:50PM +0800, yuankuiz@codeaurora.org
> wrote:
>> From 304cec1cc42255fbd9e231a810f4eea20ab74b90 Mon Sep 17 00:00:00 2001
>> From: John Zhao <yuankuiz@codeaurora.org>
>> Date: Sat, 24 Mar 2018 13:01:32 +0800
>> Subject: [PATCH] cgroup: __cpuset_node_allowed return bool
>>
>> as a bool, __cpuset_node_allowed(...) return should be bool.
>
> So, as a minor cleanup patch, this is fine but can you please soften
> the commit title / description a bit? It doesn't have to be bool.
> int is fine. bool may be marginally more readable but that's about
> it, so let's please make the commit match that.
[ZJ] In detail, Considering the conversion after it could be compiled
into asm such as: // cross compile it was done by
"arm-linux-androideabi-gcc" on ubuntu
1) return int type variable in bool function:
bool enabled()
{
int ret = 1;
return ret;
}
/**
* ... ...
* mov r3, #1
* str r3, [fp, #-8]
* ldr r3, [fp, #-8]
* cmp r3, #0
* movne r3, #1
* moveq r3, #0
* uxtb r3, r3
* ... ...
*/
2)
bool enabled()
{
bool ret = 1;
return ret;
}
/**
* ... ...
* mov r3, #1
* strb r3, [fp, #-5]
* ldrb r3, [fp, #-5] @ zero_extendqisi2
* ... ...
*/
so the #1) style function can generate significant instructions than
the #2).
While, this is happened only when "-On" is not used with *-gcc
together. Though, it is oftern there, it is best to provide this with
decoupling of which option is used for optimization.
Situation is only nice to have this change as test_bit() is interpreted
in difference way in differece arch, which is "inline int" actually in
arm-arch. Which makes the situation is not the like like the general
case but needs to be checked and continued in the general include
section.
So mark this change as nice to have to keep the thing as simple as
possible as this is what can be found under /linux/kernel related to
this point.
> Thanks.
Thanks,
BR//Zhao
next prev parent reply other threads:[~2018-03-26 14:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-24 4:56 [PATCH]cgroup: __cpuset_node_allowed return bool yuankuiz
2018-03-24 5:05 ` yuankuiz
2018-03-26 14:12 ` Tejun Heo
2018-03-26 14:20 ` yuankuiz [this message]
2018-03-26 14:25 ` Tejun Heo
2018-03-26 14:37 ` yuankuiz
2018-03-26 14:41 ` yuankuiz
2018-03-27 16:45 ` yuankuiz
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=3540bc7869927f54c409b697c743938a@codeaurora.org \
--to=yuankuiz@codeaurora.org \
--cc=cgroups-owner@vger.kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=pkondeti@codeaurora.org \
--cc=tj@kernel.org \
/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