[Bug 270785] Performance and power efficiency regression due to pthread_cond_timedwait() changes
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 16 Apr 2023 08:50:51 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270785
--- Comment #10 from bllcha013@myuct.ac.za ---
Thank you, I applied the diff on a clean git clone on releng/13.2 and tested,
but unfortunately it doesn't appear to have any effect. The sysctl is visible
as kern.ipc.umtx_min_timeout. I set it to 10ms (10000000ns) by issuing "sysctl
kern.ipc.umtx_min_timeout=10000000" but unfortunately there doesn't seem to be
any effect. CPU usage stays the same. Here's the truss and dtrace output:
syscall seconds calls errors
__sysctlbyname 0.000986089 6 0
getrusage 0.008186177 106 0
sched_yield 1.172105081 28475 0
_umtx_op 30.594233465 28659 28654
------------- ------- -------
31.775510812 57246 28654
dtrace: description 'fbt::do_wait:entry ' matched 1 probe
CPU ID FUNCTION:NAME
5 18113 do_wait:entry struct _umtx_time {
struct timespec _timeout = {
time_t tv_sec = 0x16a
long tv_nsec = 0x279c2e2a
}
__uint32_t _flags = 0x1
__uint32_t _clockid = 0x4
}
6 18113 do_wait:entry struct _umtx_time {
struct timespec _timeout = {
time_t tv_sec = 0x16a
long tv_nsec = 0x279dd9fd
}
__uint32_t _flags = 0x1
__uint32_t _clockid = 0x4
}
It seems the high volume of syscalls stayed the same, with the same short 0.1ms
delay.
Assuming this can be made to work though, this tunable would be really greatly
appreciated.
--
You are receiving this mail because:
You are the assignee for the bug.