Messages in this thread | | | From | jim.cromie@gmail ... | Date | Fri, 6 Oct 2023 14:49:27 -0600 | Subject | Re: [PATCH v1] dynamic_debug: add support for logs destination |
| |
On Wed, Oct 4, 2023 at 4:55 AM Łukasz Bartosik <lb@semihalf.com> wrote: > > wt., 3 paź 2023 o 22:54 <jim.cromie@gmail.com> napisał(a): > > > > On Tue, Oct 3, 2023 at 1:57 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > > > > > On Mon, 2 Oct 2023 14:49:20 -0600 > > > jim.cromie@gmail.com wrote: > > > > > > > hi Lukasz, > > > > > > > > sorry my kernel-time has been in my own trees. > > > > > > > > What I dont understand is why +T is insufficient. > > > > > > We would like to be able to separate debug logs from different > subsystem (e.g. thunderbolt and usbcore). > With +T it is not possible because all debug logs will land in the same bucket. > > > > > IIUC, tracefs is intended for production use. > > > > thats why each event can be enabled / disabled > > > > - to select and minimize whats traced, and not impact the system > > > > > > > > and +T can forward all pr_debugs to trace, > > > > (by 1-few trace events defined similarly to others) > > > > or very few, giving yet another selection mechanism > > > > to choose or eliminate specific pr-debugs and reduce traffic to > > > > interesting stuff. > > > > > > > > Once your debug is in the trace-buf, > > > > shouldnt user-space be deciding what to do with it ? > > > > a smart daemon could leverage tracefs to good effect. > > > > > > Yes, a daemon could separate the debug logs but IMHO it is much > easier to separate logs by sending them directly from a given subsystem > to a separate trace instance. My proposal allows to configure different > trace instance as destination for each callsite. > > > > > IMO the main value of +T is that it allows feeding existing pr_debugs > > > > into the place where other trace-data is already integrated and managed. > > > > > > > > At this point, I dont see any extra destination handling as prudent. > > > > > > > > > > > > > I'm fine with either approach. I kind of like the creation of the instance, > > > as that allows the user to keep this debug separate from other tracing > > > going on. We are starting to have multiple applications using the tracing > > > buffer (although most are using instances, which is why I'm trying to make > > > them lighter weight with the eventfs code). > > > > > > -- Steve > > > > > Steve, thanks for commenting from the trace perspective. > > > > > > > Ok Im starting to grasp that multiple instances are good > > (and wondering how I didnt notice) > > > > What doesnt thrill me is the new _ddebug field, it enlarges the footprint. > > > > Yes it increases _ddebug structure by a pointer size. > > > can you make it go away ? > > I implemented my proposal with flexibility in mind so that if someone > would like to add > another destination in the future it should be easy to do. I > understand that adding a pointer > to the _ddebug structure increases footprint size that's why I also > added CONFIG_DYNAMIC_DEBUG_DST > kernel configuration option in order to enable/disable this functionality. > > > I have some thoughts .. > > Please share your thoughts. I'm sure we can come to an agreement how > to incorporate both +T and my proposal.
So heres what Im thinking:
shrink lineno, get 2-3 bits back. last I checked largest C file is <32kloc largest header is ~120kloc, but its a data only, no pr_debugs will suddenly appear there.
define a dst_id field with 3 bits 0 is for main tracebuf 1-7 is for other instances
then the alt-dest lookup is avoided except when the dst_id field is >0
It might work to put the alt-dst-pointer into the classmaps, so the destination is used for the entire group of debugs forex DRM_UT_CORE etc.
But its no better than the dst_id field, which is per-callsite, and entirely independent of classes.
> Thanks, > Lukasz
| |