lkml.org 
[lkml]   [2006]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Fix WARN_ON / WARN_ON_ONCE regression
Tim Chen wrote:
> I think if the condition changes between two evaluations, we do have a
> problem with my fix.

That's not the problem; one hopes that the WARN_ON predicate has no
side-effects (though I know there are places which have side effects in
BUG_ON). The point is that the vast majority of WARN_ONs *don't* have
their values used, so in the current code the variable reference is dead
code and will be removed. But if gcc can't prove the predicate is
side-effect free (call to an external function, for example), then gcc
will have to generate two calls to it, regardless of whether the second
value is used.

And since the condition variable will - at worst - be stored on the
stack on a hot cache line, I don't see how there could be any extra
cache misses.

> I don't have a better idea to avoid using a local
> variable to store the condition. I think we should at least reverse the
> WARN_ON/WARN_ON_ONCE patch if a better way cannot be found.

I don't think you've proved your case here. Do you *know* there are
extra cache misses (ie, measuring them), or is it just your theory to
explain a performance regression?

The other question is whether WARN_ON should return a value. Where does
it get used? It doesn't seem very valuable.

J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-10-04 06:43    [W:0.212 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site