From: Nishanth Menon <nm@ti.com>
To: "dedekind1@gmail.com" <dedekind1@gmail.com>
Cc: linux-omap <linux-omap@vger.kernel.org>,
Kevin Hilman <khilman@deeprootsystems.com>,
"Gopinath, Thara" <thara@ti.com>
Subject: Re: [PM-SR] [PATCH 5/7] omap3: sr: device: add unlikely checks
Date: Fri, 9 Jul 2010 09:23:15 -0500 [thread overview]
Message-ID: <4C3730D3.8040309@ti.com> (raw)
In-Reply-To: <1278684927.9953.119.camel@localhost>
Artem Bityutskiy had written, on 07/09/2010 09:15 AM, the following:
> On Fri, 2010-07-09 at 08:40 -0500, Nishanth Menon wrote:
>> Artem Bityutskiy had written, on 07/09/2010 08:12 AM, the following:
>>> On Fri, 2010-06-25 at 16:46 -0500, Nishanth Menon wrote:
>>>> Add unlikely checks to better optimize the rare occurrance of
>>>> erroneous conditions.
>>>>
>>>> Cc: Kevin Hilman <khilman@deeprootsystems.com>
>>>> Cc: Thara Gopinath <thara@ti.com>
>>>>
>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>> unlikely and friends make sens only in realy hot path places. In other
>>> places like you touch, they are pointless - better let gcc make a choice
>>> @@ -43,8 +43,9 @@ static void __init sr_read_efuse(struct omap_sr_dev_data *dev_data,
>>> {
>>> int i;
>>>
>>> - if (!dev_data || !dev_data->volts_supported || !dev_data->volt_data ||
>>> - !dev_data->efuse_nvalues_offs) {
>>> + if (unlikely(!dev_data || !dev_data->volts_supported ||
>>> + !dev_data->volt_data ||
>>> + !dev_data->efuse_nvalues_offs)) {
>>> @@ -87,8 +88,8 @@ static void __init sr_set_testing_nvalues(struct omap_sr_dev_data *dev_data,
>>> {
>>> int i;
>>>
>>> - if (!dev_data || !dev_data->volts_supported ||
>>> - !dev_data->volt_data || !dev_data->test_nvalues) {
>>> + if (unlikely(!dev_data || !dev_data->volts_supported ||
>>> + !dev_data->volt_data || !dev_data->test_nvalues)) {
>> and other places, why do you think that these are checks that should be
>> expected? - would be great if you can explain inline to the patch which
>> unlikely checks dont make sense.
>>
>> static functions such as these are helpers for the maincode, unless
>> something horribly wrong occurs within the codepath calling these
>> helpers, they are not expected to be invalid parameters. hence the
>> rationale for adding unlikely.
>
> Sorry, I do not really understand you. All I said is that
> unlikely()/likely() are usually used in hot-paths / tight loops.
>
> unlikely()/likely() are micro optimization. They make no difference when
> you use them in initialization paths.
>
> So what I said, that in your patch they will make no difference
> performance wise. So no benefits.
>
> But they make if () statements a bit more difficult to read, this is a
> drawback.
>
> So your patch introduces no benefits, just a drawback. Thus, it is not
> good.
>
> There were many flamewars about unlikely and likely in lkml in the past.
> And the outcome was always - do not use them anywhere except of
> performance-critical tight loops / hot paths.
>
>
alright.. thanks for the review. will drop this patch.
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2010-07-09 14:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-25 21:46 [PM-SR] [PATCH 0/7] Janitor series 2: cleanups Nishanth Menon
2010-06-25 21:46 ` [PM-SR] [PATCH 1/7] omap3: voltage: cleanup pr_xxxx Nishanth Menon
2010-06-25 21:46 ` [PM-SR] [PATCH 2/7] omap3: sr: cleanup pr_xxx Nishanth Menon
2010-06-25 21:46 ` [PM-SR] [PATCH 3/7] omap3: sr: enable/disable sr only if required Nishanth Menon
2010-06-25 21:46 ` [PM-SR] [PATCH 4/7] omap3: sr: device: cleanup pr_xxx Nishanth Menon
2010-06-25 21:46 ` [PM-SR] [PATCH 5/7] omap3: sr: device: add unlikely checks Nishanth Menon
2010-07-09 13:12 ` Artem Bityutskiy
2010-07-09 13:40 ` Nishanth Menon
2010-07-09 14:15 ` Artem Bityutskiy
2010-07-09 14:23 ` Nishanth Menon [this message]
2010-06-25 21:46 ` [PM-SR] [PATCH 6/7] omap3: sr: device: check for dev_attr Nishanth Menon
2010-06-25 21:46 ` [PM-SR] [PATCH 7/7] omap3: sr: device: fail sr_dev_init should return error Nishanth Menon
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=4C3730D3.8040309@ti.com \
--to=nm@ti.com \
--cc=dedekind1@gmail.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=thara@ti.com \
/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;
as well as URLs for NNTP newsgroup(s).