| 1 |
Mark David Dumlao <madumlao <at> gmail.com> writes: |
| 2 |
|
| 3 |
> > PyTimeChart is another wonderful tool that complements |
| 4 |
> > Ftrace/trace-cmd/KernelShark. |
| 5 |
|
| 6 |
> > PyTimeChart is also wonderful in that it provides a graphical way to |
| 7 |
> > spot problems quickly. Most major (linux) distros have both PyTimeChart |
| 8 |
> > and Ftrace/trace-cmd/KernelShark. Together folks use PyTimeChart to |
| 9 |
> > monitor and identify low-level or low-level-application-interaction |
| 10 |
> > problems, and then use Ftrace/trace-cmd/KernelShark for fine grain |
| 11 |
> > filtering, collection and analysis of those |
| 12 |
> > low-level-application-interaction issues. |
| 13 |
|
| 14 |
> Im just going to go out on a limb here, but is it possible that you |
| 15 |
> dont understand what either systemd or pytimechart do? |
| 16 |
|
| 17 |
Huh? Extolling validation tools indicates a lack of understanding? |
| 18 |
Perhaps you ought to repond to what's written, rather than interpreting |
| 19 |
the "tea leaves"? The issue is other distros have tools to evaluate |
| 20 |
kernel performance, yet there seems to be a lack of those tools in gentoo; |
| 21 |
why? |
| 22 |
|
| 23 |
> both your description of pytimechart and the rejection of intel's |
| 24 |
> claim... seem to point to a lack of understanding. |
| 25 |
|
| 26 |
False. You are reading something else into the response. |
| 27 |
|
| 28 |
> Intel isnt saying systemd is amazing only that it doesnt operate by |
| 29 |
> spawning many short-lived processes in the same way as upstart or |
| 30 |
> sysvinit (which start shell scripts which start programs). systemd |
| 31 |
> starts the services directly based on the contents of the units. |
| 32 |
|
| 33 |
You are making way to many assumptions about what I actually wrote. I did |
| 34 |
not even distinguish between the types of "events" you are using to |
| 35 |
to discredit a posting that does not require discredit. It's merely |
| 36 |
imformative an yet another suggestion to get a tool into portage |
| 37 |
where folks that use gentoo, can tremendously benefit. Todays |
| 38 |
kernel development tools are tomorrows kernel/system debug tools, often |
| 39 |
imho. |
| 40 |
|
| 41 |
|
| 42 |
> pytimechart cannot be used to monitor events - its just a visualizer |
| 43 |
> for existing trace mechanisms. |
| 44 |
|
| 45 |
Here you go again, reading more into what was posted than what is acutally |
| 46 |
said. Furthermore, if you do not like what others write, you twist your |
| 47 |
interpretation around by denegrading others. Why? I specifically did |
| 48 |
not use the term "real time" so that it could be batch monitoring. I did |
| 49 |
not drill down to that level of differentialtions. Most monitoring is |
| 50 |
not real time. RT monitoring is a special case of "monitoring". If a |
| 51 |
"parent" gets up every so often to look at the "child processes" and then |
| 52 |
relaxes for a while, sure it's not real time (constant) with microsecond |
| 53 |
delays, but it is still monitoring. In fact if you want to break it down |
| 54 |
(split hairs) humans are not capable of real-time monitoring, as our |
| 55 |
naturaly delay in everything we do is mostly 200-500 ms, which definately |
| 56 |
does not count as RT. |
| 57 |
|
| 58 |
I've previously used a "very loose" application of "monitoring"; perhaps |
| 59 |
you should be a bit more charitable (non-assuming) in your responses |
| 60 |
and stay focused on the desired focus of the original poster's thread; |
| 61 |
or just not respond at all? Maybe start your on thread on low-level |
| 62 |
kernel tools for (gentoo) folks to use to evaluation kernel tweaks? |
| 63 |
|
| 64 |
|
| 65 |
> > I have not opened a bug requesting PyTimeChart. |
| 66 |
> perhaps you should. |
| 67 |
|
| 68 |
Perhaps someone capable should work on the Ftrace/trace-cmd/kerneshark |
| 69 |
bug first, before the community asks for ancillary tools? |
| 70 |
|
| 71 |
Often, I write generalize viewpoints, soliciting folks to respond |
| 72 |
based on there leanings, prejudices or some other form of inate-bias-tilting |
| 73 |
in their response. What I wrote is actually "complementary" to Intel and |
| 74 |
systemd. Go read it again; and stop jumping all over what I write. It would |
| 75 |
be better for some low-level tools to be put into portage, so |
| 76 |
folks can convince themselves on many "blind" issues about *their kernels*. |
| 77 |
|
| 78 |
What I do not understand is why the resistance to these low-level tools? |
| 79 |
If I had the skills to put Ftrace/trace-cmd/kernelshark into an ebuild |
| 80 |
I would have done that already. If you follow this list there are many |
| 81 |
issues that Ftrace/trace-cmd/kernelshark and pytimechart would be useful for |
| 82 |
kernel users to see what is going on with *their kernels*. |
| 83 |
|
| 84 |
This ought to get you started: |
| 85 |
|
| 86 |
http://zougloub.eu/overlay/sys-kernel/trace-cmd/ |
| 87 |
|
| 88 |
hth, |
| 89 |
James |
Archives