[Bug 270785] Performance and power efficiency regression due to pthread_cond_timedwait() changes

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 16 Apr 2023 12:48:19 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270785

--- Comment #12 from bllcha013@myuct.ac.za ---
Thank you, I applied the updated patch and tested, now Java seems to hang after
Minecraft server has started when the sysctl kern.ipc.umtx_min_timeout is set
to anything except 0. I tried 1, 10, 100000, 10000000, etc... which all
resulted in a hang, but 0 is perfectly fine. These are the last few lines from
truss when Java hangs and the truss output stops. WCPU usage of java process
drops to 0%. Only way to stop it at this point is kill -9.

_umtx_op(0x27cea36b0188,UMTX_OP_MUTEX_WAIT,0x0,0x0,0x0) = 0 (0x0)
_umtx_op(0x27cea36b0188,UMTX_OP_MUTEX_WAIT,0x0,0x0,0x0) = 0 (0x0)
_umtx_op(0x27cea36b0188,UMTX_OP_MUTEX_WAIT,0x0,0x0,0x0) = 0 (0x0)
_umtx_op(0x27cea36b0188,UMTX_OP_MUTEX_WAKE2,0x0,0x0,0x0) = 0 (0x0)
_umtx_op(0x27cea36b0188,UMTX_OP_MUTEX_WAIT,0x0,0x0,0x0) = 0 (0x0)
_umtx_op(0x27cea36b0188,UMTX_OP_MUTEX_WAIT,0x0,0x0,0x0) = 0 (0x0)
_umtx_op(0x27cea36b0188,UMTX_OP_MUTEX_WAKE2,0x0,0x0,0x0) = 0 (0x0)
_umtx_op(0x27cea36b0188,UMTX_OP_MUTEX_WAIT,0x0,0x0,0x0) = 0 (0x0)
__sysctlbyname("vm.stats.vm.v_free_count",24,0x27d0328ecc04,0x27d0328ecbf8,0x0,0)
= 0 (0x0)
__sysctlbyname("vm.stats.vm.v_cache_count",25,0x27d0328ecc04,0x27d0328ecbf8,0x0,0)
= 0 (0x0)
__sysctlbyname("vm.stats.vm.v_inactive_count",28,0x27d0328ecc04,0x27d0328ecbf8,0x0,0)
= 0 (0x0)
mprotect(0x27ceb6394000,65536,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0)
__sysctlbyname("vm.stats.vm.v_free_count",24,0x27d047c69c04,0x27d047c69bf8,0x0,0)
= 0 (0x0)
__sysctlbyname("vm.stats.vm.v_cache_count",25,0x27d047c69c04,0x27d047c69bf8,0x0,0)
= 0 (0x0)
__sysctlbyname("vm.stats.vm.v_inactive_count",28,0x27d047c69c04,0x27d047c69bf8,0x0,0)
= 0 (0x0)

In addition, when the sysctl is set to anything except 0, dtrace shows this
output from the moment I start Java/Minecraft to the moment it freezes:

dtrace: description 'fbt::do_wait:entry ' matched 1 probe

If I set the sysctl back to 0, kill and restart Java/Minecraft, then dtrace
shows lots of output as expected. As soon as I set the sysctl again, then
dtrace output immediately stops as well as truss output, leaving the above.
It's as if it is not entering do_wait at all when the sysctl is set?

-- 
You are receiving this mail because:
You are the assignee for the bug.