On Thu, May 27, 2021 at 12:01:23PM -0700, Andi Kleen wrote: > > > Nevertheless, it is quite possible that real-world use will result in > > some situation requiring that high-stress workloads run on hardware > > not designed to accommodate them, and also requiring that the kernel > > refrain from marking clocksources unstable. > > Therefore, provide an out-of-tree patch that reacts to this situation > > out-of-tree means it will not be submitted? > > I think it would make sense upstream, but perhaps guarded with some option. The reason I do not intend to immediately upstream this patch is that it increases the probability that a real clocksource read-latency issue will be ignored, for example, during hardware bringup. Furthermore, the only known need from it comes from hardware that is, in the words of the stress-ng man page, "poorly designed". And the timing of this email thread leads me to believe that such hardware is not easy to obtain. Adding an option would increase complexity, but I agree that such an option would address some of the patch's downsides. On the other hand, there has been some pushback to such options. My thought is therefore to keep this patch out of tree for now. If it becomes clear that long-latency clocksource reads really are a significant issue in their own right (as opposed to merely being a symptom of a hardware or firmware bug), then this patch is available to immediately respond to that issue. And there would then be strong evidence in favor of me biting the bullet, adding the complexity and the additional option (with your Suggested-by), and getting that upstream and into -stable. Seem reasonable? Thanx, Paul
