Messages in this thread | | | Subject | Performance of del_timer_sync | From | shobhit dayal <> | Date | Sat, 25 Sep 2004 16:37:25 +0530 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |