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

From: <bugzilla-noreply_at_freebsd.org>
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.