On 08/17/2012 08:45 PM, Joe Perches wrote:
> On Fri, 2012-08-17 at 20:15 +0200, Jiri Slaby wrote:
>> On 08/17/2012 07:39 PM, Joe Perches wrote:
>>> On Fri, 2012-08-17 at 15:42 +0200, Jiri Slaby wrote:
>>>> Before calling __ratelimit in __WARN_RATELIMIT, check the condition
>>>> first. When this check was not there, we got constant income of:
>>>> tty_init_dev: 60 callbacks suppressed
>>>> tty_init_dev: 59 callbacks suppressed
>>> []
>>>> diff --git a/include/linux/ratelimit.h b/include/linux/ratelimit.h
>>> []
>>>> @@ -49,8 +49,9 @@ extern int ___ratelimit(struct ratelimit_state *rs,
>>>> const char *func);
>>>> #define __WARN_RATELIMIT(condition, state, format...) \
>>>> ({ \
>>>> int rtn = 0; \
>>>> - if (unlikely(__ratelimit(state))) \
>>>> - rtn = WARN(condition, format); \
>>>> + int __rtcond = !!condition; \
>>>> + if (unlikely(__rtcond && __ratelimit(state))) \
>>>> + rtn = WARN(__rtcond, format); \
>>>> rtn; \
>>>> })
>>>>
>>>
>>> Hi Jiri.
>>>
>>> This seems fine to me but are there any conditions that
>>> are computationally expensive?
>>
>> It's not about expensiveness of the computation. The complexity remained
>> the same except I moved the computation one layer up.
>
> If ratelimit(state) is not true, condition wasn't tested
> or performed at all. With this change, it's always done.
Ah, you meant this. Actually this was wrong/unexpected. When devs pass
something to a function/macro they expect it to be evaluated. Exactly once.
Like in this (maybe not so good) code:
void put_ref(int refcnt) {
WARN_RATELIMIT(!--refcnt, "refcnt reached 0 unexpectedly");
}
You want the refcnt to be decremented no matter what ratelimit() returns.
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
