John Kacur <jkacur@xxxxxxxxxx> writes: > On Thu, 30 Sep 2021, John Ogness wrote: > >> On 2021-09-30, John Kacur <jkacur@xxxxxxxxxx> wrote: >> >>>> With hackbench, the system is sufficiently busy to avoid the going >> >>>> into idle. >> >>> >> >>> Not just that. cyclictest's usage of /dev/cpu_dma_latency has the side >> >>> effect that it may disable some of the PM stuff in the system. >> >>> So your system appears good but then when cyclictest is gone, the >> >>> numbers go up. >> >>> >> >>> Maybe we should drop that so we observe a system without altering its >> >>> behaviour? >> >> >> >> +1 >> >> >> >> Developers wanting to explicitly cause this behavior can use --latency= >> >> to enable it. Having it on as a default is misleading. >> > >> > Where does this "--latency=" option apply to? > > I see this option was dropped from the help, will add it back. > >> >> It is the value written to /dev/cpu_dma_latency, which AFAIK writes the >> maximum acceptable latency (in microseconds). This translates to the >> allowed C states. cyclictest currently writes 0, which should keep the >> processor in C0. For example, setting it to 1-5, should allow C0 and C1. >> >> Using --laptop will cause cyclictest to avoid touching >> /dev/cpu_dma_latency. But nobody would know that unless they looked at >> the code. >> >> IMHO, systems should be configured for production use and cyclictest >> should just _measure_ latencies at a specified priority level. But by >> default cyclictest is adjusting global system behavior during >> measurements, thus providing results that the system (as it is actually >> configured) would not be able to provide. > > The thing is, we are not just trying to measure an environment, we are > also simulating a realtime application. If your realtime environment > doesn't disable c-states, then your realtime application probably > should. I agree something (firmware, OS, application) should disable c-states - cyclictest doing it during measurements hides the fact that the system isn't configured correctly for applications requiring low latencies. I do too lean towards "altering system behaviour is better left outside the application" as different system have different knobs and need different tweaking to achieve low latency. > It's always a question of are we trying to measure a worse case scenario > or a best case scenario. > > If I remove this default we're going to get a slew of reports from people > using cyclictest wondering why they aren't getting good realtime > performance. Perhaps, this is a change best done with a major version bump. Not that it'll stop users queries completely but hopefully more people will pay attention to the changelog. [...]
