[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49F1A59B.3080206@cn.fujitsu.com>
Date: Fri, 24 Apr 2009 19:42:19 +0800
From: Zhaolei <zhaolei@...fujitsu.com>
To: Ingo Molnar <mingo@...e.hu>
CC: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Tom Zanussi <tzanussi@...il.com>, linux-kernel@...r.kernel.org,
Oleg Nesterov <oleg@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: [PATCH 0/4] workqueue_tracepoint: Add worklet tracepoints for worklet
lifecycle tracing
Ingo Molnar wrote:
> ...
> 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.
>
> 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
>
Hello, Ingo
These patchs add tracepoints for per-worklet tracing.
Now we have enough tracepoints to start makeing trace_workqueue.c support
worklet time mesurement.
Thanks
Zhaolei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists