Messages in this thread | | | Date | Mon, 17 Jan 2011 07:49:58 -0600 | Subject | Re: [PATCH] tracing, perf : add cpu hotplug trace events | From | Vincent Guittot <> |
| |
On 14 January 2011 12:35, Frederic Weisbecker <fweisbec@gmail.com> wrote: > On Fri, Jan 07, 2011 at 07:25:08PM +0100, Vincent Guittot wrote: >> On 7 January 2011 16:12, Frederic Weisbecker <fweisbec@gmail.com> wrote: >> >> + >> >> + TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid), >> > >> > I feel a bit uncomfortable with these opaque type and step. >> > >> > What about splitting the events: >> > >> > cpu_down_start >> > cpu_down_end >> > >> > cpu_up_start >> > cpu_up_end >> > >> > This ways they are much more self-explanatory. >> > >> > I also feel uncomfortable about exposing arch step details in core >> > tracepoints. >> > >> > But if we consider the following sequence: >> > >> > cpu_down() { >> > __cpu_disable() { >> > platform_cpu_disable(); >> > } >> > } >> > >> > Then exposing start/end of cpu_disable() makes sense, by way of: >> > >> > cpu_arch_disable_start >> > cpu_arch_disable_end >> > >> > cpu_arch_enable_start >> > cpu_arch_enable_end >> > >> > >> > cpu_arch_die_start >> > cpu_arch_die_end >> > >> > cpu_arch_die_start >> > cpu_arch_die_end >> > >> > Because they are arch events that you can retrieve everywhere, the tracepoints >> > are still called from the code code. >> > >> > Now for the machine part, it's very highly arch specific, most notably for arm >> > so I wonder if it would make more sense to keep that seperate into arch >> > tracepoints. >> > >> >> May be we could find some event names that matches for all system and >> that can be kept in the same file ? > > But that's only an ARM concern, right? So ARM can create its own > set of tracepoints for that. If that becomes more widely useful then > we can think about gathering the whole into a single file. >
OK, we can do like that
>> > How does that all look? I hope I'm not overengineering. >> > >> >> that's could be ok for me, I can find almost the same kind of >> information with this solution. I just wonder what traces are the >> easiest to treat for extracting some latency measurement or to treat >> with other event like the power event. > > Hmm, I'm not sure what you mean. You want to know which tracepoints > can be useful to measure latencies? Well, it depends on what kind > of latency you seek in general: scheduler, io, etc... >
I was just wondering which tracepoints format between my 1st proposal and yours was the easier to post process by an application like pytimechart.
I have updated the cpu hotplug tracepoint according to your remarks and steve's ones. I have just replaced the second cpu_arch_die_start/end in your proposal by cpu_arch_dead_start/endfrq -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |