Re: [PATCH v2] trace: Schedule a delayed work to call wakeup()

From: Vaibhav Nagarnaik
Date: Tue May 17 2011 - 16:07:37 EST

On Tue, May 17, 2011 at 11:01 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> On Tue, 2011-05-10 at 13:27 -0700, Vaibhav Nagarnaik wrote:
>> The patch schedules a delayed work after 2 ms once an event commit calls
>> to wake up the trace wait_queue. This removes the delay caused by
>> contention on spin lock in wakeup() and amortizes the wakeup() calls
>> scheduled over the 2 ms period.
>> In the following example, the script enables the sys_enter_getuid and
>> sys_exit_getuid tracepoints and runs the getuid_microbench in parallel
>> with the given number of processes. The output clearly shows the latency
>> increase caused by contentions.
> Have you taken a look at irq_work() instead of delayed work? This would
> probably allow us to call the wakeup version for all events.
> See kernel/perf_events.c for details.
> -- Steve

I looked at irq_work() as used in perf_event.c and changed the ftrace
wakeup logic to that. I found that the latencies are still bad and don't
scale very well. Mostly because the contention moved to irq_work_queue
and in the irq work handler.

The reason to have delayed work is to have the wakeups amortize over
different calls and it is easier because all the events have a common
wakeup logic.

Also, when you talk about having a wakeup version for events, do you see
different wakeup handlers depending on the event? I can see that perf
has struct irq_work as part of the event structure, but every event has
the same wakeup handler.

Vaibhav Nagarnaik
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at