On Fri, Dec 4, 2020 at 8:42 AM Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > On Thu, Dec 03, 2020 at 08:53:17PM -0700, Jim Cromie wrote: > > drm's debug system uses distinct categories of debug messages, mapped > > to bits in drm.debug. Currently, code does a lot of unlikely bit-mask > > checks on drm.debug (in drm_debug_enabled), we can use dynamic debug > > instead, and get all that jump_label goodness. > > whatis jump_label? Sorry, I should have at least capitalized that, and spelled it differently kernel/Makefile 118:obj-$(CONFIG_JUMP_LABEL) += jump_label.o it is the hot-patching substrate underneath it all. static-key, static-call, etc? dynamic-debug uses static-key directly. > > One thing that bugs me about the current drm_dbg() stuff is that > it's a function, and thus we pay the cost of setting up the > arguments even when debugs are not enabled. I played around a bit > with making it a macro again with the unlikely bit check moved > into the macro. That did seem to make some of the asm a bit nicer > where the debug stuff got shoved out the main codepath, but > it did result in a slight net increase in code size. What I didn't > have time to do is check if this has any measurable speed effect > on eg. TEST_ONLY commits. > > And while doing that I started to ponder if we could use something > like the alternate() instruction stuff to patch the code at runtime > in order to turn all those debug checks into nops when debugging > is not enabled. But I couldn't immediately find any generic > infrastructure for it. So now I wonder if this jump_label is something > like that? > this is the droid youre looking for ;-) > > > -- > Ville Syrjälä > Intel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
