Date: Sat, 26 Feb 2022 23:11:31 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 262215] Two imprecisions in cputime counters Message-ID: <bug-262215-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262215 Bug ID: 262215 Summary: Two imprecisions in cputime counters Product: Base System Version: 13.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: firk@cantconnect.ru Created attachment 232127 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D232127&action= =3Dedit patch for 10.4 - 14-CURRENT =3D=3D=3D=3D=3D=3D kern_tc.c/cputick2usec() =3D=3D=3D=3D=3D=3D > uint64_t cputick2usec(uint64_t tick) { > if (tick > 18446744073709551LL) /* floor(2^64 / 1000) */ > return (tick / (cpu_tickrate() / 1000000LL)); > else if (tick > 18446744073709LL) /* floor(2^64 / 1000000) */ > return ((tick * 1000LL) / (cpu_tickrate() / 1000LL)); > else > return ((tick * 1000000LL) / cpu_tickrate()); > } There is huge precision loss from dividing cpu_tickrate() by 1000 or 1000000 (up to 0.025% in the second case for 4GHz CPU). Worse, it will result in useconds step after reaching these two thresholds. Let's see: CPU 3999999999 Hz tick =3D 18446744073709 (real time 1:16:51.686019) usec =3D 18446744073709*1000000/3999999999 =3D 4611686019 =3D 1:16:51.686019 next usec =3D 18446744073710*1000/3999999 =3D 4611687171 =3D 1:16:51.687171 diff =3D 1152 usec (not so big, and such a step may be caused by a lot of s= ources anytime, but it is a fake step anyway) tick =3D 18446744073709551 (real time 53D 9:01:26.019580) usec =3D 18446744073709551*1000/3999999 =3D 4611687171349 =3D 53D 9:01:27.1= 71349 (note already 1 sec imprecise) next usec =3D 18446744073709552/3999 =3D 4612839228234 =3D 53D 9:20:39.2282= 34 diff =3D 19 minutes! =3D=3D=3D=3D=3D=3D kern_time.c/cputick2timespec() =3D=3D=3D=3D=3D=3D (it is used for clock_gettime() for querying process or thread consumed cpu time) Uses cputick2usec() and then needlessly converting usec to nsec, obviously losing precision even with fixed cputick2usec(). =3D=3D=3D=3D=3D=3D kern_time.c/kern_clock_getres() =3D=3D=3D=3D=3D=3D Uses some weird (anyway wrong) formula for getting cputick resolution. ------- patch attached the patch was done for 12.3, but may be applied succesfully to any version = from 10.4 to CURRENT --=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-262215-227>