On Tue, Mar 29, 2016 at 04:29:07PM -0400, Steven Rostedt wrote:

On Tue, 29 Mar 2016 22:11:45 +0200
Peter Zijlstra [off-list ref] wrote:

quoted

quoted

Yes, we don't want to get rid of the old one. But it shouldn't break
anything if we extend it. I'm thinking of extending it with a dynamic
array to store the deadline task values (runtime, period). And for non
deadline tasks, the array would be empty (size zero). I think that
could be doable and maintain backward compatibility.  

Why the complexity? Why not just tack those 32 bytes on and get on with
life?

32 bytes that are zero and meaningless for 99.999% of scheduling?

The scheduling tracepoint is probably the most common tracepoint used,
and one of the frequent ones. 32bytes of wasted space per event can
cause a lot of tracing to be missed.

Typically you don't schedule _that_ often. Sure if you run pipe-bench
and hit ~.5e6 ctx/s its ~15M/s extra. But building a kernel gets me
~.5e3 ctx/s (per cpu), at which rate its 15K/s extra.

But sure, if you want to make it fancy have at.