On Tue, Oct 15, 2013 at 02:24:40PM -0700, Joe Perches wrote:
> On Tue, 2013-10-15 at 23:12 +0200, Frederic Weisbecker wrote:
> > On Tue, Oct 15, 2013 at 02:00:05PM -0700, Joe Perches wrote:
> > > On Tue, 2013-10-15 at 22:50 +0200, Frederic Weisbecker wrote:
> > > []
> > > > diff --git a/include/linux/printk.h b/include/linux/printk.h
> > > []
> > > > @@ -252,14 +253,7 @@ extern asmlinkage void dump_stack(void) __cold;
> > > >
> > > > #ifdef CONFIG_PRINTK
> > > > #define printk_once(fmt, ...) \
> > > > -({ \
> > > > - static bool __print_once; \
> > > > - \
> > > > - if (!__print_once) { \
> > > > - __print_once = true; \
> > > > - printk(fmt, ##__VA_ARGS__); \
> > > > - } \
> > > > -})
> > > > + DO_ONCE(printk(fmt, ##__VA_ARGS__));
> > >
> > > It's hard to believe the overhead is worth it.
> >
> > Which overhead?
>
> The one you were proposing with xchg
>
> Apparently the 1/3 series you submitted
> didn't use it.
>
> Given that it didn't, does the indirection
> to DO_ONCE really help?
Yes, the diffstat has more "-" than "+" :o)
But we might get the xchg() in the end. Andrew proposed
a nice tradeoff against the performance issue:
if (!__warned)
return;
__old_warned = xchg(__warned, 1);
if (!__old_warned)
do_warning
>
> btw:
>
> https://lkml.org/lkml/2009/5/21/300
>
> Perhaps Alan's comment still applies:
>
> https://lkml.org/lkml/2009/5/21/305
Alan was right having such a macro handy is tempting to use in a driver or so,
and that would be most of the time for bad reasons. It's not an object
synchronization.
Now I don't entirely agree with him because it consolidates existing code. It's
a
good CPP library when something really needs a global state to execute something
only once.
It's especially useful for debugging. I mean I often miss such a macro. I use
very
often the following pattern for debugging:
static int done;
if (!done) {
trace_printk(something);
trace_printk(something else);
trace_dump_stack();
done = 1;
}
Having a DO_ONCE() would help a lot I think.
Now we can rename it to __DO_ONCE() and put a big fat comment to avoid it
to be misused.
Hm?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
