forked from Minki/linux
829a999625
The ".acq" semantics of the load only apply w.r.t. other data access. Reading the clock (ar.itc) isn't a data access so strange things can happen here. Specifically the read of ar.itc can be launched as soon as the read of xtime_lock.sequence is ISSUED. Since this may cache miss, and that might cause a thread switch, and there may be cache contention for the line containing xtime_lock, it may be a long time before the actual value is returned, so the ar.itc value may be very stale. Move the consumption of r28 up before the read of ar.itc to make sure that we really have got the current value of xtime_lock.sequence before look at ar.itc. Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: Tony Luck <tony.luck@intel.com> |
||
|---|---|---|
| .. | ||
| configs | ||
| dig | ||
| hp | ||
| ia32 | ||
| kernel | ||
| lib | ||
| mm | ||
| oprofile | ||
| pci | ||
| scripts | ||
| sn | ||
| defconfig | ||
| install.sh | ||
| Kconfig | ||
| Kconfig.debug | ||
| Makefile | ||
| module.lds | ||