(+ LKML) Apologies forgot to CC the list.
On 04/07/19 18:52, Qais Yousef wrote: > Hi Steve, Peter > > I know the topic has sprung up in the past but I couldn't find anything that > points into any conclusion. > > As far as I understand new TRACE_EVENTS() in the scheduler (and probably other > subsystems) isn't desirable as it intorduces a sort of ABI that can be painful > to maintain. > > But for us to be able to test various aspect of EAS, we rely on some events > that track load_avg, util_avg and some other metrics in the scheduler. > Example of such patches that are in android and we maintain out of tree can be > found here: > > https://android.googlesource.com/kernel/common/+/42903694913697da88a4ac627a92bbfdf44f0a2e > https://android.googlesource.com/kernel/common/+/6dfaed989ea4ca223f0913dfc11cdafd9664fc1c > > Dietmar and Quentin pointed me to a discussion you guys had with Daniel > Bristot > in the last LPC when he had a similar need. So it is something that could > benefit other users as well. > > What is the best way forward to be able to add tracehooks into the scheduler > and any other subsystem for that matters? > > We tried using DECLARE_TRACE() to create a tracepoint which doesn't export > anything in /sys/kernel/debug/tracing/events and hoped that we can use eBPF or > a kernel module to attach to this tracepoint and access the args to inject our > own trace_printks() but this didn't work. The glue logic necessary to attach > to this tracepoint in a similar manner to how RAW_TRACEPOINT() in eBPF works > isn't there AFAICT. > > I can post the full example if the above doesn't make sense. I am still > familiarizing myself with the different aspects of this code as well. There > might be support for what we want but I failed to figure out the magic > combination to get it to work. > > If I got this glue logic done, would this be an acceptable solution? If not, > do > you have any suggestions on how to progress? > > Thanks > > -- > Qais Yousef
