Notes from the LPC scheduler microconference

Posted Sep 22, 2017 13:10 UTC (Fri) by nix (subscriber, #2304)
In reply to: Notes from the LPC scheduler microconference by karim
Parent article: Notes from the LPC scheduler microconference

Surely the thing to do here is what DTrace has long done: add stability metadata to tracepoints, with the default being 'unstable, can go away at any time' and stability only ever being guaranteed for conceptually-stable tracepoints tracing things that aren't going to go away however the kernel changes, like "process creation" or "read()". Consumers of these tracepoints then have to explicitly say that they know they are using an unstable tracepoint via some explicit option: otherwise, only stable ones are visible.

Notes from the LPC scheduler microconference

Posted Sep 22, 2017 17:01 UTC (Fri) by karim (subscriber, #114) [Link] (2 responses)

That's an interesting approach. I certainly think it has the merit of being discussed.

But from my point of view, they should all be seen as "can go away at any time". I would think that that should it make more palatable for maintainers to accept them -- and easier to garbage-collect them at any time. I bet it's even possible to create a script that allows user-space-tool-maintainers to identify trace point deltas from one version to the next and adjust their code accordingly.

Still, I see your point. In fact, that's the point I argued on the LKML circa 2005/2006 when I was still getting pushback on the LTT patches. I essentially showed that the trace points I had in 1999 and 2005/6 were essentially the same set and, hence, the whole argument about unmaintainability was overblown. IOW, some events are always going to take place in any Unix-like kernel: system calls, sched changes, interrupt entries, etc.

It's a good argument for having the trace points part of the sources. It doesn't mean they should be considered ABI. In fact, trace points are likely closer to the driver API than the system call API in terms of long-term consistency guarantees. The former can change at any time, the latter never should.

Notes from the LPC scheduler microconference

Posted Sep 25, 2017 10:35 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

While "consider everything unstable" is attractive to kernel hacker,s there are some tracepoints it doesn't make sense to erase, mostly those that map to syscalls and to user-visible operations, you'll never have a kernel that doesn't create processes, so tracepoints of that nature are stable; nor will you one that removes already-present syscalls like read(), so that tracepoint is stable too.

More generally, I think, the stability of a tracepoint is the same as the stability of the thing it is tracing. Function-based tracing is totally unstable because nobody expects the names of functions in the kernel to remain the same forever. Syscall tracing or proc:: process-state tracing is stable because, in the one case, there is an explicit guarantee about the stability of syscalls (at least, those that actually get used); in the other case, it is difficult to imagine a Unix-like kernel not implementing a way to create processes, or fork, and you'd attach those tracepoints to wherever it was you did that.

So I think we are in violent agreement here. (DTrace for Linux has gone further: the tracepoints, their type information, and the information about which D types they are translated to -- possibly turning one argument into many -- are all recorded nowhere but in the tracepoint declarations in the source code, and thus in a specialized section which is sucked out and parsed into argument types at DTrace module load time.)

Notes from the LPC scheduler microconference

Posted Sep 25, 2017 11:08 UTC (Mon) by nix (subscriber, #2304) [Link]

And of course not only did you say all of that yourself, more concisely, you said it without a blizzard of terrible typos.

I should not post before coffee.