On Tue, Oct 28, 2025 at 7:06 AM opensource india <[email protected]> wrote: > > Hi Zack Rusin, > > On Mon, Oct 20, 2025 at 9:48 AM Zack Rusin <[email protected]> wrote: > > > > > I don't remember exactly the schedule family of functions but isn't > > schedule_hrtimeout leaving the task in a running state? In general it > > looks like with the patch the task's current state doesn't match what > > was expected, plus I'm not sure if I quite get why the uninterruptible > > non-lazy case is being replaced with a lazy wait of NSEC_PER_MSEC's. > > It'd be great if you could explain a little bit better what you're > > doing here because the commit message is missing an explanation for > > either of those. > > > > z > > Thank you for checking the patch. > > The existing code does not specify any fixed wait time during the > fence wait. It simply invokes schedule(), > which means the task can be rescheduled immediately to check the fence > status again. > > By using the high-resolution timer family of functions, we can specify > an explicit sleep duration. > In this patch, the sleep time is set to 1 ms, ensuring that the fence > status is checked at fixed 1 ms intervals. > > This approach allows the CPU to be released to other tasks for a > deterministic period, > thereby reducing unnecessary CPU wakeups while maintaining timely > fence checks(FIXME expected the same).
Sorry, but that doesn't answer any of my questions. I can see what the patch is doing, but I'd love to know why. Same with the wait period: why have you picked 1ms? To me that seems like introducing a huge latency into fence waits, so I'd expect to see numbers that back it up. What benchmarks have you run that show the CPU utilization and FPS/score both before and after this patch that would justify that wait period? z
smime.p7s
Description: S/MIME Cryptographic Signature
