On Sat, 2013-03-16 at 18:01 +0000, Al Viro wrote: > On Sat, Mar 16, 2013 at 10:51:18AM -0700, Joe Perches wrote: > > > This is certainly a neat trick. > > > > > > But I don't really like the fact that it complicates things for every > > > future code reader, especially when a trivial change in the caller > > > would accomplish the same thing. Do you have any idea how much > > > performance we would gain in exchange for the complication? > > > > Nope. I believe it's trivial in any case. > > I just saw Steven's trace hack and thought of seq_printk. > > > > Is there a real performance sensitive seq_printf anywhere? > > ... and _that_ is the question that should've been asked first.
I totally agree with you. I've been avoiding the "performance sensitivity" question because of my narcissistic enjoyment of my macro cleverness ;-) And also because I have no "F"'n life. I just figured someone else will point out the lack of clothes the Emperor has on. > > > It's trivial to replace seq_printf("constant") with > > seq_puts but there are over a thousand of them. > > > > It may be better to just leave everything as-is. > > Quite. Note that it's not equivalent to gcc treatment of printf/puts - > there we have cases when it *is* a real hotpath (and I seriously suspect > that it's in part driven by desire to discourage people from uglifying > source by manual equivalents of that micro-optimization). Moreover, > glibc printf at least used to be heavy; kernel-side we are nowhere near > that bad. It's also a very hot path in tracing. One reason I only implemented the macro trick with trace_printk() and not printk() nor seq_printk() is because I knew those were not hot paths. The reason I created trace_puts() in the first place, is because I had a bug I was trying to debug where a trace_printk() would actually make the bug go away. It added too much of an impact to get the race to trigger. But the trace_puts() was able to do the trace and still have the bug trigger, and I was able to debug the problem. But I enjoyed this conversation while it lasted. Sorry it took up your time. But it did call to attention that these macros that create variables should probably have a naming policy to avoid macro traps. -- Steve -- 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/