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/> References: <bug-270785-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270785 --- 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= =3D100 would give a 10ms step, and kern.hz=3D1000 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.periodi= c=3D0: the step is always 0.1ms. However, using kern.eventtimer.periodic=3D1 chang= es things: it becomes 0.5ms with kern.hz=3D1000 and 2.5ms with kern.hz=3D100. >From my (limited) understanding, the commit improves the precision of timed waits, but the old behavior inadvertently helped with CPU utilization and p= ower 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-270785-227-WnDrrDaNIE>