lkml.org 
[lkml]   [2004]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectPerformance of del_timer_sync
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.040 / U:1.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site