Re: [PATCH] hrtimers: Remove the "timer_stats_active" check whensetting the start info

[Feng Tang]

On Tue, 15 Sep 2009 17:00:09 +0800
Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:

> > 
> > Recent hrtimer code will set the start info to a hrtimer only when
> > that flag is set, then the start info of all hrtimers will always
> > be uninitialised before a "echo 1 > /proc/timer_stats", thus
> > the /proc/timer_lists will have something like:
> > 
> > active timers:
> >  #0: <c27d46b0>, tick_sched_timer, S:01, <(null)>, /-1
> >  # expires at 91062000000-91062000000 nsecs [in 156071 to 156071
> > nsecs] #1: <efb81b6c>, hrtimer_wakeup, S:01, <(null)>, /-1
> >  # expires at 91062300331-91062350331 nsecs [in 456402 to 506402
> > nsecs] #2: <efac9b6c>, hrtimer_wakeup, S:01, <(null)>, /-1
> >  # expires at 91068699811-91068749811 nsecs [in 6855882 to 6905882
> > nsecs] #3: <efacdb6c>, hrtimer_wakeup, S:01, <(null)>, /-1
> >  # expires at 91068755511-91068805511 nsecs [in 6911582 to 6961582
> > nsecs] #4: <efa95b6c>, hrtimer_wakeup, S:01, <(null)>, /-1
> >  # expires at 91068806066-91068856066 nsecs [in 6962137 to 7012137
> > nsecs] .....
> > 
> > This patch will fix it.
> 
> Well, at the same time it forces the memcpy when !timer_stats_active.
> We generally want to avoid such overhead when debug facilities are
> disabled.

I understand the performance point, that's why I add a check line trying
to avoid unnecessary copy (yes, the check itself will bring some overload):
 
 void __timer_stats_hrtimer_set_start_info(struct hrtimer *timer, void *addr)
 {
-       if (timer->start_site)
+       if (timer->start_site == addr && timer->start_pid == current->pid)
                return;

Also there is one corner case, that a hrtimer get initialized and queued in
before setting timer_stats_active to 1, but get run after that. Then its
start_site will be NULL which will prevent it from being accounted. 

Thanks,
Feng


--
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/