From: Peter Zijlstra <peterz@infradead.org> To: Alexei Starovoitov <ast@plumgrid.com> Cc: Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Arnaldo Carvalho de Melo <acme@infradead.org>, Jiri Olsa <jolsa@redhat.com>, Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>, Linux API <linux-api@vger.kernel.org>, Network Development <netdev@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Linus Torvalds <torvalds@linux-foundation.org>, "Eric W. Biederman" <ebiederm@xmission.com> Subject: Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls Date: Wed, 11 Feb 2015 11:15:21 +0100 [thread overview] Message-ID: <20150211101521.GP23123@twins.programming.kicks-ass.net> (raw) In-Reply-To: <CAMEtUuzY_Po=WtFEFg1aqzJ8dEF4rHGcWDsaS44KYgACMNPPgA@mail.gmail.com> On Tue, Feb 10, 2015 at 04:22:50PM -0800, Alexei Starovoitov wrote: > > It would need to do more that that. It may have to calculate the value > > that it returns, as the internal value may be different with different > > kernels. > > back to 'prio'... the 'prio' accessible from the program > should be the same 'prio' that we're storing inside task_struct. Its not, task_struct::prio is an entirely different value than the one used in sched_param::sched_priority / sched_attr::sched_priority. And the 'problem' is, prio is only relevant to SCHED_RR/SCHED_FIFO tasks, we have more classes. > No extra conversions. We're not going to add runtime/space overhead to the kernel just because someone might maybe someday trace the kernel. That leaves the option of either tracing the kernel internal value and userspace will just have to deal with it, or making the tracepoint more expensive by having it do the conversion. Now the big question is, what do we do when we add/extend a scheduling class and have more parameters? We cannot change the tracepoint because userspace assumes format. And I simply refuse to add a second -- because that will end up being a third and fourth etc.. -- tracepoint right next to it with a different layout. Note that we just did add a class, we grew SCHED_DEADLINE a few releases ago, and that has 3 parameters (or 6 depending on how you look at it). You currently cannot 'debug' that with the existing tracepoints. In short, I loathe traceevents, they're more trouble than they're worth. Now I do love the infrastructure, its very useful debugging, but that's all with local hacks that will never see the light of day.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> To: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org> Cc: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>, Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Namhyung Kim <namhyung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Arnaldo Carvalho de Melo <acme-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>, Jiri Olsa <jolsa-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Masami Hiramatsu <masami.hiramatsu.pt-FCd8Q96Dh0JBDgjK7y7TUQ@public.gmane.org>, Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Network Development <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> Subject: Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls Date: Wed, 11 Feb 2015 11:15:21 +0100 [thread overview] Message-ID: <20150211101521.GP23123@twins.programming.kicks-ass.net> (raw) In-Reply-To: <CAMEtUuzY_Po=WtFEFg1aqzJ8dEF4rHGcWDsaS44KYgACMNPPgA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On Tue, Feb 10, 2015 at 04:22:50PM -0800, Alexei Starovoitov wrote: > > It would need to do more that that. It may have to calculate the value > > that it returns, as the internal value may be different with different > > kernels. > > back to 'prio'... the 'prio' accessible from the program > should be the same 'prio' that we're storing inside task_struct. Its not, task_struct::prio is an entirely different value than the one used in sched_param::sched_priority / sched_attr::sched_priority. And the 'problem' is, prio is only relevant to SCHED_RR/SCHED_FIFO tasks, we have more classes. > No extra conversions. We're not going to add runtime/space overhead to the kernel just because someone might maybe someday trace the kernel. That leaves the option of either tracing the kernel internal value and userspace will just have to deal with it, or making the tracepoint more expensive by having it do the conversion. Now the big question is, what do we do when we add/extend a scheduling class and have more parameters? We cannot change the tracepoint because userspace assumes format. And I simply refuse to add a second -- because that will end up being a third and fourth etc.. -- tracepoint right next to it with a different layout. Note that we just did add a class, we grew SCHED_DEADLINE a few releases ago, and that has 3 parameters (or 6 depending on how you look at it). You currently cannot 'debug' that with the existing tracepoints. In short, I loathe traceevents, they're more trouble than they're worth. Now I do love the infrastructure, its very useful debugging, but that's all with local hacks that will never see the light of day.
next prev parent reply other threads:[~2015-02-11 10:15 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-02-11 0:22 [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls Alexei Starovoitov 2015-02-11 0:50 ` Steven Rostedt 2015-02-11 0:50 ` Steven Rostedt 2015-02-11 9:33 ` Peter Zijlstra 2015-02-11 9:45 ` Peter Zijlstra 2015-02-11 9:45 ` Peter Zijlstra 2015-02-11 10:15 ` Peter Zijlstra [this message] 2015-02-11 10:15 ` Peter Zijlstra 2015-02-12 4:58 ` Hekuang 2015-02-12 4:58 ` Hekuang 2015-02-12 4:58 ` Hekuang 2015-02-16 11:26 ` He Kuang 2015-02-16 11:26 ` He Kuang -- strict thread matches above, loose matches on Subject: below -- 2015-02-23 18:55 Alexei Starovoitov 2015-02-23 18:55 ` Alexei Starovoitov 2015-02-14 23:02 Alexei Starovoitov 2015-02-14 23:02 ` Alexei Starovoitov 2015-02-14 22:54 Alexei Starovoitov 2015-02-14 22:54 ` Alexei Starovoitov 2015-02-14 22:48 Alexei Starovoitov 2015-02-14 22:48 ` Alexei Starovoitov 2015-02-11 6:33 Alexei Starovoitov 2015-02-11 6:33 ` Alexei Starovoitov 2015-02-11 12:51 ` Steven Rostedt 2015-02-11 12:51 ` Steven Rostedt 2015-02-11 3:04 Alexei Starovoitov 2015-02-11 4:31 ` Steven Rostedt 2015-02-11 4:31 ` Steven Rostedt 2015-02-10 19:53 Alexei Starovoitov 2015-02-10 21:53 ` Steven Rostedt 2015-02-10 21:53 ` Steven Rostedt 2015-02-11 10:28 ` Peter Zijlstra 2015-02-11 10:28 ` Peter Zijlstra 2015-02-10 6:10 Alexei Starovoitov 2015-02-10 6:10 ` Alexei Starovoitov 2015-02-10 13:05 ` Steven Rostedt 2015-02-10 13:05 ` Steven Rostedt 2015-02-10 5:51 Alexei Starovoitov 2015-02-10 5:51 ` Alexei Starovoitov 2015-02-10 12:27 ` Steven Rostedt 2015-02-10 3:45 [PATCH v3 linux-trace 0/8] tracing: attach eBPF programs to tracepoints/syscalls/kprobe Alexei Starovoitov 2015-02-10 3:45 ` [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls Alexei Starovoitov 2015-02-10 3:45 ` Alexei Starovoitov 2015-02-10 4:46 ` Steven Rostedt 2015-02-10 4:46 ` Steven Rostedt 2015-02-10 5:13 ` Steven Rostedt 2015-02-10 5:13 ` Steven Rostedt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150211101521.GP23123@twins.programming.kicks-ass.net \ --to=peterz@infradead.org \ --cc=acme@infradead.org \ --cc=ast@plumgrid.com \ --cc=ebiederm@xmission.com \ --cc=jolsa@redhat.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=masami.hiramatsu.pt@hitachi.com \ --cc=mingo@kernel.org \ --cc=namhyung@kernel.org \ --cc=netdev@vger.kernel.org \ --cc=rostedt@goodmis.org \ --cc=torvalds@linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.