On Fri, Nov 15, 2024 at 11:05 PM Len Brown <lenb@xxxxxxxxxx> wrote: > > > Performance lower than the possible maximum doesn't necessarily count as "bad". > > System resume slower than 1 second will fail multiple product acceptance tests. > > That isn't good, it is bad :-) > > > > Re: if long sleeps then use msleep() > > > > > > ... because a jiffy based timer effectively forces coalescing, and is > > > the lowest overhead. > > > > > > The problem with this logic is, as you mention, coalescing is a > > > function of the distribution of timer expirations over time,it is not > > > a function of the duration of those timers. > > > > I just think that high precision is not necessary for long timeouts. > > > > I also don't think that ASL programmers expect high precision in those cases. > > Precision isn't the question. > The benefit of additional delay is the question. > > ie. if an ASL programmer asks for Sleep(100), they expect it to take > no less than 100ms. > > msleep(100) takes 106ms -- effectively always. For HZ=250. > usleep-range(100,100) takes 100ms, effectively always. > > Is the additional 6ms delay really worth the saved overhead of using > jiffies rather than a timer for an ACPI flow? Or the other way around, is the better timer precision worth the additional overhead? AFAICS, the reason why you are pushing so hard for this is suspend/resume delays due to loops of many iterations that sleep for a short time in every iteration. I'm kind of having a hard time with accepting the argument that the kernel needs to be made to use more resources always in the ACPI path to address just this one case.
