On Wed, Nov 20, 2024 at 7:38 PM Arjan van de Ven <arjan@xxxxxxxxxxxxxxx> wrote: > > On 11/20/2024 10:03 AM, Rafael J. Wysocki wrote: > > On Tue, Nov 19, 2024 at 4:08 PM Arjan van de Ven <arjan@xxxxxxxxxxxxxxx> wrote: > >> > >> On 11/19/2024 5:42 AM, Rafael J. Wysocki wrote: > >>> On Mon, Nov 18, 2024 at 3:35 PM Arjan van de Ven <arjan@xxxxxxxxxxxxxxx> wrote: > >>>> > >>>>> And the argument seems to be that it is better to always use more > >>>>> resources in a given path (ACPI sleep in this particular case) than to > >>>>> be somewhat inaccurate which is visible in some cases. > >>>>> > >>>>> This would mean that hrtimers should always be used everywhere, but they aren't. > >>>> > >>>> more or less rule of thumb is that regular timers are optimized for not firing case > >>>> (e.g. timeouts that get deleted when the actual event happens) while hrtimers > >>>> are optimized for the case where the timer is expected to fire. > >>> > >>> I've heard that, which makes me wonder why msleep() is still there. > >>> > >>> One thing that's rarely mentioned is that programming a timer in HW > >>> actually takes time, so if it is done too often, it hurts performance > >>> through latency (even if this is the TSC deadline timer). > >> > >> yup and this is why you want to group events together "somewhat", and which is why > >> we have slack, to allow that to happen > > > > So what do you think would be the minimum slack to use in this case? > > > > I thought about something on the order of 199 us, but now I'm thinking > > that 50 us would work too. Less than this - I'm not sure. > > 50 usec is likely more than enough in practice. And would you use the same slack value regardless of the sleep duration, or make it somehow depend on the sleep duration?
