Mark David Dumlao <madumlao <at> gmail.com> writes: > > PyTimeChart is another wonderful tool that complements > > Ftrace/trace-cmd/KernelShark.
> > PyTimeChart is also wonderful in that it provides a graphical way to > > spot problems quickly. Most major (linux) distros have both PyTimeChart > > and Ftrace/trace-cmd/KernelShark. Together folks use PyTimeChart to > > monitor and identify low-level or low-level-application-interaction > > problems, and then use Ftrace/trace-cmd/KernelShark for fine grain > > filtering, collection and analysis of those > > low-level-application-interaction issues. > Im just going to go out on a limb here, but is it possible that you > dont understand what either systemd or pytimechart do? Huh? Extolling validation tools indicates a lack of understanding? Perhaps you ought to repond to what's written, rather than interpreting the "tea leaves"? The issue is other distros have tools to evaluate kernel performance, yet there seems to be a lack of those tools in gentoo; why? > both your description of pytimechart and the rejection of intel's > claim... seem to point to a lack of understanding. False. You are reading something else into the response. > Intel isnt saying systemd is amazing only that it doesnt operate by > spawning many short-lived processes in the same way as upstart or > sysvinit (which start shell scripts which start programs). systemd > starts the services directly based on the contents of the units. You are making way to many assumptions about what I actually wrote. I did not even distinguish between the types of "events" you are using to to discredit a posting that does not require discredit. It's merely imformative an yet another suggestion to get a tool into portage where folks that use gentoo, can tremendously benefit. Todays kernel development tools are tomorrows kernel/system debug tools, often imho. > pytimechart cannot be used to monitor events - its just a visualizer > for existing trace mechanisms. Here you go again, reading more into what was posted than what is acutally said. Furthermore, if you do not like what others write, you twist your interpretation around by denegrading others. Why? I specifically did not use the term "real time" so that it could be batch monitoring. I did not drill down to that level of differentialtions. Most monitoring is not real time. RT monitoring is a special case of "monitoring". If a "parent" gets up every so often to look at the "child processes" and then relaxes for a while, sure it's not real time (constant) with microsecond delays, but it is still monitoring. In fact if you want to break it down (split hairs) humans are not capable of real-time monitoring, as our naturaly delay in everything we do is mostly 200-500 ms, which definately does not count as RT. I've previously used a "very loose" application of "monitoring"; perhaps you should be a bit more charitable (non-assuming) in your responses and stay focused on the desired focus of the original poster's thread; or just not respond at all? Maybe start your on thread on low-level kernel tools for (gentoo) folks to use to evaluation kernel tweaks? > > I have not opened a bug requesting PyTimeChart. > perhaps you should. Perhaps someone capable should work on the Ftrace/trace-cmd/kerneshark bug first, before the community asks for ancillary tools? Often, I write generalize viewpoints, soliciting folks to respond based on there leanings, prejudices or some other form of inate-bias-tilting in their response. What I wrote is actually "complementary" to Intel and systemd. Go read it again; and stop jumping all over what I write. It would be better for some low-level tools to be put into portage, so folks can convince themselves on many "blind" issues about *their kernels*. What I do not understand is why the resistance to these low-level tools? If I had the skills to put Ftrace/trace-cmd/kernelshark into an ebuild I would have done that already. If you follow this list there are many issues that Ftrace/trace-cmd/kernelshark and pytimechart would be useful for kernel users to see what is going on with *their kernels*. This ought to get you started: http://zougloub.eu/overlay/sys-kernel/trace-cmd/ hth, James
