| Message ID | 20211216021649.7273-1-hongzhan.chen@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | kernel-shark: Add plugin for handling Xenomai cobalt_context_switch. | expand |
On Wed, 15 Dec 2021 21:16:48 -0500 Hongzhan Chen <hongzhan.chen@intel.com> wrote: > I do not know if this patch can be accepted in upstream from function's > view because it is xenomai related which still be different from > pure kernel-shark for pure linux. But it is still independent plugin > which would not influence other kernel-shark's functions and the plugin > would not take effect if there is no cobalt_switch_context event found > in trace data. We are perfectly happy to accept plugins for various OSs, not just pure Linux :-) Welcome to the KernelShark Community. Note, Yordan is now the maintainer of KernelShark so I'll let him review the patches. Thanks! -- Steve
On 16.12.21 04:03, Steven Rostedt wrote: > On Wed, 15 Dec 2021 21:16:48 -0500 > Hongzhan Chen <hongzhan.chen@intel.com> wrote: > >> I do not know if this patch can be accepted in upstream from function's >> view because it is xenomai related which still be different from >> pure kernel-shark for pure linux. But it is still independent plugin >> which would not influence other kernel-shark's functions and the plugin >> would not take effect if there is no cobalt_switch_context event found >> in trace data. > > We are perfectly happy to accept plugins for various OSs, not just pure > Linux :-) > We were just wondering how to handle potential (we have no concrete case so far) variations of trace points along releases of those "various OSs" best and were therefore also considering maintaining the plugin in lock-step with the Xenomai releases. How does KernelShark manage such cases? Thanks, Jan
Hi all, On 16.12.21 г. 9:11 ч., Jan Kiszka wrote: > On 16.12.21 04:03, Steven Rostedt wrote: >> On Wed, 15 Dec 2021 21:16:48 -0500 >> Hongzhan Chen <hongzhan.chen@intel.com> wrote: >> >>> I do not know if this patch can be accepted in upstream from function's >>> view because it is xenomai related which still be different from >>> pure kernel-shark for pure linux. But it is still independent plugin >>> which would not influence other kernel-shark's functions and the plugin >>> would not take effect if there is no cobalt_switch_context event found >>> in trace data. >> >> We are perfectly happy to accept plugins for various OSs, not just pure >> Linux :-) >> > > We were just wondering how to handle potential (we have no concrete case > so far) variations of trace points along releases of those "various OSs" > best and were therefore also considering maintaining the plugin in > lock-step with the Xenomai releases. How does KernelShark manage such cases? > I am adding Dario and Giuseppe to the loop, because they may de interested in this work. We can take the plugin upstream as long as it does not add any xenomai specific dependencies (headers or libraries). In such case you have to guarantee a persistent commitment for co-maintaining it. Alternatively, you can maintain the plugin in a stand alone repository. Dario and Giuseppe are doing this. Cheers, Yordan > Thanks, > Jan >
On Thu, 16 Dec 2021 14:29:00 +0200 Yordan Karadzhov <y.karadz@gmail.com> wrote: > > We were just wondering how to handle potential (we have no concrete case > > so far) variations of trace points along releases of those "various OSs" > > best and were therefore also considering maintaining the plugin in > > lock-step with the Xenomai releases. How does KernelShark manage such cases? > > > > I am adding Dario and Giuseppe to the loop, because they may de interested in this work. > > We can take the plugin upstream as long as it does not add any xenomai specific dependencies (headers or libraries). > In such case you have to guarantee a persistent commitment for co-maintaining it. > Alternatively, you can maintain the plugin in a stand alone repository. Dario and Giuseppe are doing this. I believe Jan is asking about this stand alone like scenario. Where the plugin is actually maintained in the Xenomai repository. Is there a way to have the KernelShark user config file automatically load a plugin? That way a user could have the plugins they are interested in (that are not part of the main repository) automatically loaded every time they start KernelShark? -- Steve
On 16.12.21 г. 14:36 ч., Steven Rostedt wrote: > On Thu, 16 Dec 2021 14:29:00 +0200 > Yordan Karadzhov <y.karadz@gmail.com> wrote: > >>> We were just wondering how to handle potential (we have no concrete case >>> so far) variations of trace points along releases of those "various OSs" >>> best and were therefore also considering maintaining the plugin in >>> lock-step with the Xenomai releases. How does KernelShark manage such cases? >>> >> >> I am adding Dario and Giuseppe to the loop, because they may de interested in this work. >> >> We can take the plugin upstream as long as it does not add any xenomai specific dependencies (headers or libraries). >> In such case you have to guarantee a persistent commitment for co-maintaining it. >> Alternatively, you can maintain the plugin in a stand alone repository. Dario and Giuseppe are doing this. > > I believe Jan is asking about this stand alone like scenario. Where the > plugin is actually maintained in the Xenomai repository. > > Is there a way to have the KernelShark user config file automatically load a > plugin? That way a user could have the plugins they are interested in (that > are not part of the main repository) automatically loaded every time they > start KernelShark? Currently not, but this can be implemented. Y. > > -- Steve >
For Xenomai-cobalt enabled system, cobalt_switch_context means that there is context switch in companion core(realtime core), which we may need to do special treatment and take correct action as main kernel sched_switch to visualize out-of-band state of realtime tasks running in cobalt core. To achive our target, we implement following: 1. store corresponding cobalt_switch_context events into container data. 2. modify pid stored in entry to be equal to next_pid to show correct color in cpu bar when cobalt_switch_context event happen. 3. show blue hollow box to mark out-of-band state underneath the baseline of task plots according to cobalt_switch_context events. 4. clickable cobalt_switch_context plugin shapes. I do not know if this patch can be accepted in upstream from function's view because it is xenomai related which still be different from pure kernel-shark for pure linux. But it is still independent plugin which would not influence other kernel-shark's functions and the plugin would not take effect if there is no cobalt_switch_context event found in trace data. Hongzhan Chen (1): kernel-shark: Add plugin for handling Xenomai cobalt_context_switch src/libkshark-tepdata.c | 1 + src/plugins/CMakeLists.txt | 4 + src/plugins/CobaltSwitchEvents.cpp | 204 +++++++++++++++++++++ src/plugins/xenomai_cobalt_switch_events.c | 198 ++++++++++++++++++++ src/plugins/xenomai_cobalt_switch_events.h | 64 +++++++ 5 files changed, 471 insertions(+) create mode 100644 src/plugins/CobaltSwitchEvents.cpp create mode 100644 src/plugins/xenomai_cobalt_switch_events.c create mode 100644 src/plugins/xenomai_cobalt_switch_events.h