On 27 October 2015 at 20:46, Leonid Yegoshin <Leonid.Yegoshin@xxxxxxxxxx> wrote: > I doesn't work in this way - a standard CP0_counter synchronization code > takes up to hundred milliseconds to complete with running some loop cycles > on two CPUs. It is clearly seen in Malta FPGA board. > > Non-standard (one way sync, write CP0_counter value to memory in CPU0 before > CPU1 wakeup) is not precise because it can't predict how much time the CPU1 > can spent in wakeup. Just because of HW, for exam, and SW next. > > I believe, until this issue is fixed the R4K only CPU should be excluded > from VDSO timing acceleration. The VDSO code will currently use the CP0 count whenever the kernel is using it as its primary clocksource, aside from the case where RDHWR is broken as it is on old QEMUs. Maybe I'm missing something but I don't see anything in the generic timekeeping code that handles the same clocksource being unsynchronised or running at a different rate on different CPUs. Given that, if you think there is an issue that prevents the VDSO from using it then that would surely affect the kernel as well and needs to be fixed separately? If it really is necessary to prevent the VDSO from using a certain clocksource even though the kernel is using it, it should be a simple matter of setting clocksource.archdata.vdso_clock_mode to VDSO_CLOCK_NONE. This is how this patch stops it using the CP0 count when RDHWR is broken. Alex
