[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.