On Tue, Aug 3, 2021 at 1:27 PM Bernd Petrovitsch
<bernd@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi all!
>
> On 03/08/2021 20:43, jim.cromie@xxxxxxxxx wrote:
> [...]
> > there are many uses of :
> > pr_debug("%s ...\n", __func__, ...)
> >
> > I tried to do a preprocessor catenation to replace the runtime work,
> > but that falls afoul of the def.
>
> And that's a feature because preprocessor concatenation bloats the
> kernels memory footprint massively.
>
> [...]
> > is there a kernel macro version that would allow this "optimization" ?
>
> pr_*() are slow per se so optimizing there (apart from readability and
> size od code+data) is wasted time.
Im not after optimization per se.
but wrt it, best optimization is to not print, except when its useful.
thats the value of dyndbg, silence until you need it.
dynamic-debug lets you selectively enable pr_debug()s by their properties
- module, function, filename, lineno, format
all but last are properties of code organization,
format uniquely contains "Application" context.
in DRM context, that context could be any of DRM_UT_<category>
If that category-info is in the format string (at compile time)
then dynamic-debug can operate on the app-info in it too.
Then dyndbg can replace drm_debug_enabled(), and save cycles.
Ive done this, Daniel Vetter liked it, so unless Im hit by a bus, I
will finish it.
https://patchwork.freedesktop.org/series/92544/
Im just looking for corner cases of its applicability.
note: __func__ and others are available from dyndbg framework, ( +pmfl )
So callsites doing too is "overhead" unless youre avoiding dyndbg
( memory use would be a 1st reason not to use it)
In any case, if __func__ worked like a macro, the "optimization" would
be available.
And because its in the format, this would work
echo "format $_func_name +p" > /proc/dynamic_debug/control
of course, so would:
echo "func $_func_name +p" > /proc/dynamic_debug/control
but for that, you'd need to know func.
to get it, you could
echo +fm > /proc/dynamic_debug/control
anyway, thats FMTYNTK
thanks
Jim
>
> MfG,
> Bernd
> --
> Bernd Petrovitsch Email : bernd@xxxxxxxxxxxxxxxxxxx
> There is NO CLOUD, just other people's computers. - FSFE
> LUGA : http://www.luga.at
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
