* [gentoo-user] Re: Systemd and PyTimeChart
2014-09-23 21:14 ` Mark David Dumlao
@ 2014-09-24 13:22 ` James
0 siblings, 0 replies; 3+ messages in thread
From: James @ 2014-09-24 13:22 UTC (permalink / raw
To: gentoo-user
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
^ permalink raw reply [flat|nested] 3+ messages in thread