Re: [PATCH 3/4] sched/deadline: Tracepoints for deadline scheduler
From: Steven Rostedt <rostedt@goodmis.org>
Date: 2016-02-23 13:10:52
Also in:
lkml
On Tue, 23 Feb 2016 11:44:08 +0100 Peter Zijlstra [off-list ref] wrote:
No it very much illustrates the problem and is a very clear indication that tracepoints are an ABI.
Yes they are. But note, they can change if nobody notices ;-)
quoted
Heh, it's not really changing state. The code directly after this is: p->dl.runtime = 0;Yes, it more or less 'works', but its still atrocious shite. Its the worst kind of anti pattern possible. Suppose someone comes and removes that line, and ignores the tracepoint stuff, because, hell its a tracepoint, those don't modify stuff. Its just really, utterly bad practice. You've done this tracing code long enough, you really should _KNOW_ this.
You're right. I got too caught up in the cleverness of the hack to acknowledge it is a hack. But Daniel has a patch to clean up the yield code which would also help in making this hack unnecessary for this tracepoint.
quoted
quoted
So tell me why these specific tracepoints and why the existing ones could not be extended to include this information. For example, why a trace_sched_dealine_yield, and not a generic trace_sched_yield() that works for all classes.But what about reporting actual runtime, and when the next period will come. That only matters for deadline.How is that an answer to the question? Are you implying a generic trace_sched_yield() call could not do this?quoted
quoted
But do not present me with a bunch of random arse, hacked together tracepoints and tell me they might be useful, maybe.They ARE useful. These are the tracepoints I'm currently using to debug the deadline scheduler with. They have been indispensable for my current work.They are, most obviously, a hacked together debug session for sure. This is _NOT_ what you commit. Now ideally we'd do something like the below, but because trainwreck, we cannot actually do this I think :-( It gets you about half of what your patch does, but shows how to also do a generic sched_yield(). The replenish might have to remain special, although both CFS and RT also have replenishes, albeit significantly different.
OK, I admit. I was very single focused on deadline scheduler. I wasn't looking at how this could work with the rest of the scheduler. I'll take a look at the patches you posted. Thanks! -- Steve