On Thu, May 27, 2021 at 05:58:53PM -0700, Andi Kleen wrote: > > > Only those cloud provides making heavy use of the aforementioned "poorly > > designed" hardware, correct? > > If any such hardware is deployed in non homeopathic quantities, we probably > need to support it out of the box. So far I'm not seeing any evidence that > it does not. > > That would argue for including the patch in the patch series. > > Especially since stress-ng is somewhat popular for system testing. Except that different use cases need different out-of-the-box settings. In addition, there is a range of consequences for undesired settings across these use cases. Fortunately, the various distros and other kernel delivery mechanisms act as different boxes, and can provide their chosen out-of-box setting. Of course, it would be better to avoid adding an additional setting. But as we will see when considering the following use cases and corresponding consequences, that setting needs to be to mark the clocksource unstable if that clocksource exhibits persistent read delays, that is, as the v15 series does -without- the out-of-tree patch. To see this, consider the following use cases: o Bringup testing for new silicon, firmware, and clock drivers. In this case, it is critically important that any serious problem be unmistakably flagged. After all, these activities are all too often carried out under severe time pressure, which means that subtle messages are likely to be ignored. If there is a hardware, firmware, or driver issue that results in persistent delays, this issue must not be ignored. Hence the absolute need to mark the clocksource unstable in this case, in order to avoid releasing hardware, firmware, and clock-driver bugs into the wild. o System test for new hardware, including multisocket hardware such as that denigrated by stress-ng. Although this use case might prefer that clocksource read delays be ignored (as they would be with my out-of-tree patch [1]), there are a number of good-and-sufficient ways to deal with the current state of the v15 series [2], including marking the TSC stable, specifying HPET at boot time, or simply ignoring the fact that the clocksource gets marked unstable. o Applications running in production that suffer from stress-ng-like properties. Such applications might well prefer that high-speed fine-grained clocksources not be marked unstable, but the workarounds for system test apply here as well. Furthermore, such applications are likely to perform better on a single-socket system than on a larger and more expensive multi-socket system. Thus, marking clocksources unstable would be a good hint that adjustments would be helpful, whether these adjustments be confining such applications to lower-cost hardware on which they are likely to perform better, or reading a certain book [3] and applying its lessons in order to adjust the application to improve performance and scalability and to reduce the interference with clocksources. o Scalable applications running in production, as in those that do not suffer from stress-ng-like properties. Any such applications that are sensitive to clock skew in excess of 100 microseconds really want the v15 series without the extra patch. After all, if there is a problem with clock-related hardware, firmware, or device-driver bugs, it is far better to have that problem unambiguously diagnosed than to have to wade through strange and misleading application problems caused by clock skew. And please note that this is not a theoretical problem. After all, an earlier version of this series already spotted a very real problem that was addressed by an upgrade. So if there is only a single out-of-the box option, it really does need to be that provided by v15 of the patch series. There are already settings that can be used in the use cases that care, but if these prove inadequate, again, I can add another setting via a new patch, perhaps based on my out-of-tree patch. Thanx, Paul [1] https://lore.kernel.org/lkml/20210527182959.GA437082@paulmck-ThinkPad-P17-Gen-1/ [2] https://lore.kernel.org/lkml/20210527190042.GA438700@paulmck-ThinkPad-P17-Gen-1/ [3] https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html
