On Fri, Aug 20, 2021, Mathieu Desnoyers wrote:
I still really hate flakiness in tests, because then people stop caring when they
fail once in a while. And with the nature of rseq, a once-in-a-while failure is a
big deal. Let's see if we can use other tricks to ensure stability of the cpu id
without changing timings too much.
Yeah, zero agrument regarding flaky tests.
One idea would be to use a seqcount lock.
A sequence counter did the trick! Thanks much!
But even if we use that, I'm concerned that the very long writer critical
section calling sched_setaffinity would need to be alternated with a sleep to
ensure the read-side progresses. The sleep delay could be relatively small
compared to the duration of the sched_setaffinity call, e.g. ratio 1:10.
I already had an arbitrary usleep(10) to let the reader make progress between
sched_setaffinity() calls. Dropping it down to 1us didn't affect reproducibility,
so I went with that to shave those precious cycles :-) Eliminating the delay
entirely did result in no repro, which was a nice confirmation that it's needed
to let the reader get back into KVM_RUN.
Thanks again!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel