On 11/6/20 7:47 PM, Thomas Gleixner wrote: > On Thu, Nov 05 2020 at 12:25, Carlos O'Donell wrote: >> On 10/30/20 9:38 PM, Thomas Gleixner wrote: >> If kata grows up quickly perhaps this entire problem becomes solved, but >> until >> then I continue to have a testing need for a distinct CLOCK_REALTIME in a >> time namespace (and it need not be unconditional, if I have to engage magic >> then I'm happy to do that). > > Conditional, that might be a way to go. > > Would CONFIG_DEBUG_DISTORTED_CLOCK_REALTIME be a way to go? IOW, > something which is clearly in the debug section of the kernel which wont > get turned on by distros (*cough*) and comes with a description that any > bug reports against it vs. time correctness are going to be ignored.
Yes. I would be requiring CONFIG_DEBUG_DISTORTED_CLOCK_REALTIME. Let me be clear though, the distros have *+debug kernels for which this CONFIG_DEBUG_* could get turned on? In Fedora *+debug kernels we enable all sorts of things like CONFIG_DEBUG_OBJECTS_* and CONFIG_DEBUG_SPINLOCK etc. etc. etc. I would push Fedora/RHEL to ship this in the *+debug kernels. That way I can have this on for local test/build cycle. Would you be OK with that? We could have it disabled by default but enabled via proc like unprivileged_userns_clone was at one point? I want to avoid accidental use in Fedora *+debug kernels unless the developer is actively going to run tests that require time manipulation e.g. thousands of DNSSEC tests with timeouts [1]. I also need a way to determine the feature is enabled or disabled so I can XFAIL the tests and tell the developer they need to turn on the feature in the host kernel (and not to complain when CLOCK_REALTIME is wrong). A proc interface solves this in a straight forward way. I could then also tell my hardware partners to turn it on during certain test/build cycles. It violates "ship what you test" but increases test coverage and can be run as a distinct test cycle. I could also have our internal builders turn this feature on so we can run rpm %check phases with this feature enabled (operations might refuse, but in that case my day-to-day developer testing still helps by orders of magnitude). Notes: [1] Petr Špaček commented on DNSSEC and expiration testing as another real-world testing scenario: https://sourceware.org/pipermail/libc-alpha/2020-November/119785.html Still a testing scenario, but an example outside of glibc for networking, where they have a need to execute thousands of tests with accelerated timeout. If vm+containers catches up, and I think they will, we'll have a solution in a few years. >> * Adding CLOCK_REALTIME to the kernel is a lot of work given the expected >> guarantees for a local system. > > Correct. > >> * CLOCK_REALTIME is an expensive resource to maintain, even more expensive >> than other resources where the kernel can balance their usage. > > Correct. > >> * On balance it would be better to use vm or vm+containers e.g. kata as a >> solution to having CLOCK_REALTIME distinct in the container. > > That'd be the optimal solution, but the above might be a middle ground. Agreed. -- Cheers, Carlos.
