Date: Fri, 14 Apr 2023 15:39:42 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 270785] Performance and power efficiency regression due to pthread_cond_timedwait() changes Message-ID: <bug-270785-227-WnDrrDaNIE@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-270785-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270785 --- Comment #6 from bllcha013@myuct.ac.za --- Interestingly, there is a bug report for Minecraft that seems related: https://bugs.mojang.com/browse/MC-183518 It seems that an extremely low timeout is causing massive numbers of calls per second. This issue wasn't noticeable before, but now is, probably due to the increased precision of timing allowed with the commit. For Linux, changing the value in /proc/<pid>/timerslack_ns apparently helps, but it isn't there on FreeBSD. I noticed that the difference between "steps" of the tv_nsec value in the dtrace output was seemingly tied to kern.hz before the commit, so kern.hz=100 would give a 10ms step, and kern.hz=1000 would give a 1ms step, no matter what kern.eventtimer.periodic is set to, which I confirmed with dtrace. After the commit, kern.hz doesn't seem to have an impact when kern.eventtimer.periodic=0: the step is always 0.1ms. However, using kern.eventtimer.periodic=1 changes things: it becomes 0.5ms with kern.hz=1000 and 2.5ms with kern.hz=100. >From my (limited) understanding, the commit improves the precision of timed waits, but the old behavior inadvertently helped with CPU utilization and power efficiency by preventing software from being too abusive with short timeouts and constantly waking the CPU. Please let me know if there is any other information I can provide. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-270785-227-WnDrrDaNIE>