Messages in this thread |  | | | Subject | Re: [RFC] [PATCH] Performance of del_single_shot_timer_sync | | From | shobhit dayal <> | | Date | Sun, 10 Oct 2004 15:59:36 +0530 |
| |
On Fri, 2004-10-08 at 22:49, Andrew Morton wrote: > shobhit dayal <shobhit@calsoftinc.com> wrote: > > > > del_timer_sync was responsible for about 2% of all remote memory > > accesses on the system and came up as part of the top 10 functions who > > were doing this. On top was schedule(7.52%) followed by > > default_wake_function(2.79%). Rest every one in the top 10 were > > around the range of 2%. > > > > After the patch it never came up in the logs again( so less than 0.5% of > > all faulting eip's). > > > > And what is the overall improvement from the del_timer_sync speedup patch? > I mean: overall runtime and CPU time improvements for a > relatively-real-world benchmark? >
I have Geoff's figures
Before: 32p 4p Warm cache 29,000 505 Cold cache 37,800 1220
After: 32p 4p Warm cache 95 88 Cold cache 1,800 140 [Measurements are CPU cycles spent in a call to del_timer_sync, the average of 1000 calls. 32p is 16-node NUMA, 4p is SMP.]
These figures, would apply for the case for where del_timer_sync does get called from del_single_shot_timer_sync. That is del_singe_shot_timer_sync gets called after timer has expired
For my profiling workload i used the standard pg_regress module from the postgres installation and noticed that the ratio of calls to del_single_shot_timer_sync after expiry to before expiry was 10:1. over 11000 calls to del_single_shot_timer_sync.
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/
|  |