On Tue, 23 Feb 2016 11:44:08 +0100 Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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 ;-) > > > > 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. > > > > 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? > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
