Re: [PATCH v3 1/1] ftrace, workqueuetrace: Make workqueuetracepoints use TRACE_EVENT macro

[Zhaolei]

* From: "Ingo Molnar" <mingo@xxxxxxx>
> 
> * Zhaolei <zhaolei@xxxxxxxxxxxxxx> wrote:
> 
>> +TRACE_EVENT(workqueue_insertion,
>> +TRACE_EVENT(workqueue_execution,
>> +TRACE_EVENT(workqueue_creation,
>> +TRACE_EVENT(workqueue_destruction,
> 
> I'm missing all the worklet tracepoints i suggested. (and i think 
> which you had in earlier versions)
> 
> Basically, i'd suggest the following complete set of events instead:
> 
> TRACE_EVENT(workqueue_create
> TRACE_EVENT(workqueue_flush              /* NEW */
> TRACE_EVENT(workqueue_destroy
> 
> TRACE_EVENT(worklet_enqueue              /* NEW */
> TRACE_EVENT(worklet_enqueue_delayed      /* NEW */
> 
> TRACE_EVENT(worklet_execute              /* instead of workqueue_execution */
> TRACE_EVENT(worklet_complete             /* NEW */
> 
> TRACE_EVENT(worklet_cancel               /* NEW */
> 
> This allows the understanding of the life cycle of a workqueue and 
> of worklets that enter that workqueue. Note the distinction between 
> workqueue and worklet (work) - that is essential.
Hello, Ingo

Thanks for your suggest.
I read distinction between workqueue and worklet.
In my schedule, this patch is first step of our target, my image of steps is:
  1: Move current workqueuetracepoints into TRACEEVENT (this patch)
  2: Make workqueuetrace support per-worklet output (doing)
  3: Add time information to workqueuetrace's worklet stat (need above new TRACEPOINT)

So, i prepared to add new worklet tracepoints in step3.
What's your opinion?

Thanks
Zhaolei
> 
> The parameters of the events are obvious, with one detail: i'd 
> suggest a 'cpu' parameter to the enqueue events, to allow the 
> mapping of the _on(..cpu) variants too.
> 
> I would not bother with schedule_on_each_cpu() instrumentation - 
> it's rarely used.
> 
> Ingo
> 
>N?§²æìr¸?yúè?Øb²X¬¶Ç§vØ^?)Þº{.nÇ+?·¥?{±?êçzX§¶?¡Ü¨}©?²Æ zÚ&j:+v?¨¾«?êçzZ+?Ê+zf£¢·h??§~?­?Ûiÿûàz¹®w¥¢¸??¨è­Ú&¢)ߢf?ù^jÇ«y§m?á@A«a¶Úÿ0¶ìh®å?i