On Tue, 28 Jun 2011 10:45:43 +1000 Benjamin Herrenschmidt <[email protected]> wrote:
> On Mon, 2011-06-27 at 16:56 -0500, Scott Wood wrote: > > As is done in read_tsc() on x86, make sure that we don't return a timebase > > value smaller than cycle_last, which can happen on SMP if the timebases are > > not perfectly synchronized. It is less expensive than total enforcement of > > monotonicity, since we don't need to add another variable and update it on > > each read, but it will prevent core timekeeping functions from translating > > a small timebase regression into a large jump forward. > > > > Based on commit d8bb6f4c1670c8324e4135c61ef07486f7f17379 for x86. > > You are applying a bandage on a wooden leg here .... userspace (vDSO) > will see the time going backward if you aren't well synchronized as > well, so you're stuffed anyways. Sure -- but we should avoid turning a slight backwards drift into a huge positive offset in the kernel's calculations. One way to do that is for the generic timekeeping code to be robust against this, for all time sources. The other is to apply this sort of hack on time sources that are known to possibly go backwards. The former is the better fix IMHO, but the latter is what was already done for TSC on x86, so I went with the less intrusive change. -Scott _______________________________________________ Linuxppc-dev mailing list [email protected] https://lists.ozlabs.org/listinfo/linuxppc-dev
