Performance of del_timer_sync

[shobhit dayal]

This is with reference to the del_timer_sync patch submitted by Geoff
Gustafson http://lwn.net/Articles/84839/.

I profiled a postgress load on a 8p( 4 nodes) NUMA machine. This
profiler logs functions that access memory on remote nodes, and
del_timer_sync was one of the top few functions doing this. The culprit
is the for loop in del_timer_sync that reads the running_timer field of
the per cpu tvec_bases_t structure on all nodes in the system. It gets
invoked most times from del_singleshot_timer_sync.

Andrew Morton had suggested a patch for this, when the top callers to
del_timer sync were schedule_timeout and clear_timeout, the fix being
the  del_single_shot_timer_sync patch,  with the knowledge that
schedule_timeout and clear_timeout do not create timers that re-add
themselves.

This may not be enough, the problem is that schedule_timeout at most
times will call del_single_shot_timer_sync after the timer has expired.
This will cause del_timer to asume that the handler is running on some
cpu and del_timer_sync will still get invoked.

Ofcourse, it also means that del_timer_sync will continue to be a
hotspot as far as taking up cpu time is concerned.

I tried Geoff's patch and it does seem to improve performance.

Has anyone else seen del_timer_sync as a hotspot after the
del_singleshot_timer_sync patch?

regards
Shobhit



				

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/