On Sun, Feb 04, 2018 at 11:39:39AM -0800, Linus Torvalds wrote: > Then there's the "I just want an overview" MIS people, who care about > things like "I want a histogram of packets sent according to criteria > XYZ", who want some highlevel block IO performance, or who just want > random system-wide statistics. > The second group might want explicit trace points exactly because that > group doesn't even care *how* a packet is sent or received, or what > the path through the block layer is. It just wants to know "packet > sent" or "latency between IO request and completion" or things like > that. So a large sticking point here as been the scheduler tracepoints; which I'm rather unhappy with. As a result of adding SCHED_DEADLINE the existing tracepoints no longer are sufficient (they don't provide any deadline specific information). So the MIS people that are intersted in deadline tasks are unhappy. My own preference is to just add the deadline information to the existing tracepoints, but then people complain these become too big (which is slow etc..), saying sched_switch is a high rate tracepoint (true of course) (not to mention that changing the tracepoint will probably break something, but they'll just have to cope). So they've proposed all kinds of horrible alternatives that are all variations of multiple tracepoints in the same location that fragment the information, each of which I hate. I'm ok with having the _one_ tracepoint, but I don't want 3+ sched_switch tracepoints, each having a different set of information depending on what people want, that way lies madness. As a run-around, Steve then suggested to decouple the trace-hook from the actual trace-event. Let the scheduler only provide the hook, nothing else. And then allow users to create their own events with the specific data they need for their specific use-case. Various options have been floated, ebpf, modules, whatever. At this point I'm well tired of all this and would just as soon rip out all tracepoints entire; but of course, the scheduler has some very useful information for MIS people, so we can't realy do that either. /sadface -- To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|