Evening Steve,
On 3/14/19 7:20 PM, Steven Rostedt wrote:
> On Thu, 14 Mar 2019 17:06:11 +0100
> Claudio <claudio.fontana@xxxxxxxxx> wrote:
>
>> Hi Steve,
>>
>> I have experimented with mainline, and then with mainline plus a patch to add the info for fork as well like this:
>>
>> diff --git a/kernel/trace/trace_sched_switch.c b/kernel/trace/trace_sched_switch.c
>> index e288168..c5339ed 100644
>> --- a/kernel/trace/trace_sched_switch.c
>> +++ b/kernel/trace/trace_sched_switch.c
>> @@ -47,6 +47,20 @@ probe_sched_wakeup(void *ignore, struct task_struct *wakee)
>> tracing_record_taskinfo(current, flags);
>> }
>>
>> +static void
>> +probe_sched_fork(void *ignore,
>> + struct task_struct *parent, struct task_struct *child)
>> +{
>> + int flags;
>> +
>> + flags = (RECORD_TGID * !!sched_tgid_ref) +
>> + (RECORD_CMDLINE * !!sched_cmdline_ref);
>> +
>> + if (!flags)
>> + return;
>> + tracing_record_taskinfo(child, flags);
>> +}
>> +
>> static int tracing_sched_register(void)
>> {
>> int ret;
>> @@ -72,7 +86,16 @@ static int tracing_sched_register(void)
>> goto fail_deprobe_wake_new;
>> }
>>
>> + ret = register_trace_sched_process_fork(probe_sched_fork, NULL);
>> + if (ret) {
>> + pr_info("sched trace: Couldn't activate tracepoint"
>> + " probe to kernel_sched_process_fork\n");
>> + goto fail_deprobe_switch;
>> + }
>> +
>> return ret;
>> +fail_deprobe_switch:
>> + unregister_trace_sched_switch(probe_sched_switch, NULL);
>> fail_deprobe_wake_new:
>> unregister_trace_sched_wakeup_new(probe_sched_wakeup, NULL);
>> fail_deprobe:
>> @@ -82,6 +105,7 @@ static int tracing_sched_register(void)
>>
>> static void tracing_sched_unregister(void)
>> {
>> + unregister_trace_sched_process_fork(probe_sched_fork, NULL);
>> unregister_trace_sched_switch(probe_sched_switch, NULL);
>> unregister_trace_sched_wakeup_new(probe_sched_wakeup, NULL);
>> unregister_trace_sched_wakeup(probe_sched_wakeup, NULL);
>>
>>
>> --
>>
>> It seems to work, but the model seems not to apply very well to my use case.
>>
>> saved_tgids cannot be reset, not even by disabling tracing completely
>>
>> echo 0 > tracing_on
>>
>> or
>>
>> echo 0 > options/record-tgids
>>
>> and the list just keeps growing, no entries are ever removed when tasks are destroyed etc,
>> so my lookups become more and more expensive as the list grows.
>> I don't think this is suited to be looked up frequently for my tracing scenario.
>>
>
> It shouldn't grow when you disable tracing though.
>
> Hmm, we could add a reset if one writes to the saved_* files.
>
>> Next I will experiment with:
>>
>> 1) kprobes, trying to generate an event before every sched class event carrying the tid to tgid mapping.
>
> Just plop a kprobe on top of __schedule()
>
> -- Steve
I seem to need a few of those; but it works.
However the userspace application becomes very tied to the specific kernel version and arch,
or am I missing something? Maybe there is something less tied to the kernel than the following example?
echo 'p:kprobes/wakeup_tgid ttwu_do_wakeup arg1=+2220($arg2):x32' > kprobe_events
>>
>> 2) if everything fails, revert to use /proc/PID/stat, which however can be slow and racy if the process does not exist anymore when I read back the ftrace buffers.
indeed it breaks easiy; If I just had a tgid inside the sched events format..
Anyway, will pick it up tomorrow.
Thank you, ciao,
Claudio
|