Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Apr 2023 08:50:51 +0000
From:      bugzilla-noreply@freebsd.org
To:        threads@FreeBSD.org
Subject:   [Bug 270785] Performance and power efficiency regression due to pthread_cond_timedwait() changes
Message-ID:  <bug-270785-13406-WMxsXFjD3i@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-270785-13406@https.bugs.freebsd.org/bugzilla/>
References:  <bug-270785-13406@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 #10 from bllcha013@myuct.ac.za ---
Thank you, I applied the diff on a clean git clone on releng/13.2 and teste=
d,
but unfortunately it doesn't appear to have any effect. The sysctl is visib=
le
as kern.ipc.umtx_min_timeout. I set it to 10ms (10000000ns) by issuing "sys=
ctl
kern.ipc.umtx_min_timeout=3D10000000" 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 =3D {
        time_t tv_sec =3D 0x16a
        long tv_nsec =3D 0x279c2e2a
    }
    __uint32_t _flags =3D 0x1
    __uint32_t _clockid =3D 0x4
}
  6  18113                    do_wait:entry struct _umtx_time {
    struct timespec _timeout =3D {
        time_t tv_sec =3D 0x16a
        long tv_nsec =3D 0x279dd9fd
    }
    __uint32_t _flags =3D 0x1
    __uint32_t _clockid =3D 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 grea=
tly
appreciated.

--=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-13406-WMxsXFjD3i>