Re: [v3, 3/3] MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()

From: Leonid Yegoshin
Date: Wed Oct 28 2015 - 14:21:45 EST


On 10/28/2015 03:20 AM, Alex Smith wrote:
On 27 October 2015 at 20:46, Leonid Yegoshin <Leonid.Yegoshin@xxxxxxxxxx> wrote:
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.

1) I don't see that in code - there is no check that kernel uses actually uses R4K clocksource as primary (A), and if kernel uses R4K count as a clocksource and later switches to some more precise clocksource then there is no change in VDSO gettimeofday handling (B).

2) The fact that MIPS kernel as today uses CP0_COUNT in any core as the same clocksource is correct only until first power saving event with CPU clock disabled (skipping Octeon). After that it is an incorrect use without an accurate synchronization and that synchronization doesn't exist.

And I remember that today kernel uses only CPU0 CP0_COUNT to update time... may be wrong, need to check, but that could be a good code.


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.

(I would like to skip here the generic timekeeping code capabilities, just to restrict a discussion to HW capabilities)


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.

OK, just put kernel-build time check that it is not SMP without GIC clocksource or it is Octeon. It would be enough to stop a mess.

- Leonid

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/