Messages in this thread | | | Subject | Re: BUG: using smp_processor_id() in preemptible [00000000] code: icedove-bin/5449 | From | Peter Zijlstra <> | Date | Tue, 25 May 2010 11:51:35 +0200 |
| |
On Tue, 2010-05-25 at 11:47 +0200, Peter Zijlstra wrote: > On Tue, 2010-05-25 at 11:43 +0200, Ingo Molnar wrote: > > > Subject: sched_clock: Add local_clock() > > > From: Peter Zijlstra <a.p.zijlstra@chello.nl> > > > Date: Tue May 25 10:48:51 CEST 2010 > > > > > > For people who otherwise get to write: cpu_clock(smp_processor_id()), > > > there is now: local_clock(). > > > > This doesnt fix the whole issue. cpu_clock() is local, while the measurements > > done in the blk code are global ... > > > > While the warning is fixed this way, the far more serious issue is still > > there: time can go backwards if two points of time measurement are on > > different CPUs and can mess up the statistics with negative values, etc... > > cpu_clock() is synced on each tick, so the inter-cpu-drift should not > exceed 2 jiffies. > > But yeah, if they want anything better, they'll have to start caring on > what cpu which timestamp got taken and use cpu_clock().
For completeness, the previously used sched_clock() isn't synced between cores at all, and can exhibit unbounded drift.
| |