Messages in this thread | | | Date | Mon, 9 May 2011 10:40:33 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [RFC] time: xtime_lock is held too long |
| |
On Fri, 6 May 2011, john stultz wrote: > On Sat, 2011-05-07 at 01:00 +0200, Eric Dumazet wrote: > > Le vendredi 06 mai 2011 à 15:46 -0700, john stultz a écrit : > > > On Sat, 2011-05-07 at 00:30 +0200, Eric Dumazet wrote: > > > > I can see many cpus entering tick_do_update_jiffies64() and all are > > > > calling write_seqlock(&xtime_lock); > > > > > > > > Only first one can perform the work, but all others are waiting on the > > > > spinlock, get it, change seqcount, and realize they have nothing to > > > > do... > > > > > > Huh. So who is calling tick_do_update_jiffies64 in your case? I know the > > > sched_tick_timer and tick_nohz_handler checks to make sure > > > tick_do_timer_cpu == cpu to avoid exactly the thundering heard problem > > > on the jiffies update. > > > > > > There's other spots that call tick_do_update_jiffies64, but I thought > > > those were more rare. So there may be something else wrong going on > > > here. > > > > > > > That I can answer : > [snip] > > (I added do_timestamp1/do_timestamp2) after/before write_seqlock()/write_sequnlock() > > > > <idle>-0 [003] 920.355377: do_timestamp1 <-tick_do_update_jiffies64 > > <idle>-0 [006] 920.355377: tick_do_update_jiffies64 <-tick_sched_timer > > <idle>-0 [003] 920.355378: do_timestamp2 <-tick_do_update_jiffies64 > > <idle>-0 [000] 920.355657: tick_do_update_jiffies64 <-tick_check_idle > > <idle>-0 [000] 920.355660: tick_do_update_jiffies64 <-tick_nohz_restart_sched_tick > > Thomas, any clues why this would be getting hammered?
Hmm, tick-sched code grew quite a few unconditional callsites which i'm not sure of whether they are correct.
Thanks,
tglx | |