Date: Mon, 21 Mar 2022 13:34:45 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 262215] Two imprecisions in cputime counters Message-ID: <bug-262215-227-Xgi84qxgBh@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-262215-227@https.bugs.freebsd.org/bugzilla/> References: <bug-262215-227@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=3D262215 --- Comment #5 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3Dbb53dd56c30c6360fc82be762ed98b0af= 6b9f69f commit bb53dd56c30c6360fc82be762ed98b0af6b9f69f Author: firk <firk@cantconnect.ru> AuthorDate: 2022-03-21 13:33:11 +0000 Commit: George V. Neville-Neil <gnn@FreeBSD.org> CommitDate: 2022-03-21 13:33:46 +0000 kern_tc.c/cputick2usec() (which is used to calculate cputime from cpu ticks) has some imprecision and, worse, huge timestep (about 20 minutes on 4GHz CPU) near 53.4 days of elapsed time. kern_time.c/cputick2timespec() (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(). kern_time.c/kern_clock_getres() uses some weird (anyway wrong) formula for getting cputick resolution. PR: 262215 Reviewed by: gnn Differential Revision: https://reviews.freebsd.org/D34558 lib/libkvm/kvm_proc.c | 9 ++------- sys/kern/kern_tc.c | 12 +++--------- sys/kern/kern_time.c | 12 +++++------- 3 files changed, 10 insertions(+), 23 deletions(-) --=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-Xgi84qxgBh>