]> git.puffer.fish Git - mirror/frr.git/commit
lib: Fix FreeBSD clock_gettime(CLOCK_THREAD_CPUTIME_ID,..) going backwards 10702/head
authorDonald Sharp <sharpd@nvidia.com>
Tue, 1 Mar 2022 14:02:33 +0000 (09:02 -0500)
committermergify-bot <noreply@mergify.com>
Tue, 1 Mar 2022 18:49:40 +0000 (18:49 +0000)
commita8ca407929aad445f3eafdc139af2fcdb1a06709
treeeef9a50d05deead47ce47b1755a09d08c6b1640b
parentc81e85e1ba12fa9c075559803dfcf52021acf8b5
lib: Fix FreeBSD clock_gettime(CLOCK_THREAD_CPUTIME_ID,..) going backwards

On FreeBSD I have noticed that subsuquent calls to clock_gettime(..)
can return an after time that is before first calls value.
This in turn is generating CPU_HOG's because the subtraction
is wrapping into very very large numbers:

2022/02/28 20:12:58 SHARP: [PTDQA-70FG5]     start: 35.741981000  now: 35.740581000
2022/02/28 20:12:58 SHARP: [XK9YH-ZD8FA][EC 100663313] CPU HOG: task zclient_read (800744240) ran for 0ms (cpu time 18446744073709550ms)

(Please note I added the first line of debug to figure this issue out).

I have been asked to open a FreeBSD bug report and have done so.
In the mean time I think that it is important that FRR does
not generate bogus CPU HOG's on FreeBSD ( especially since
this may or may not be easily fixed and FRR has no control
over what version of the operating system, operators are
going to be running with FRR.

So, add a bit of specialized code that checks to see if
the after time in FreeBSD is before the now time in
thread_consumed_time and do some quick manipulations
to not have this issue.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 4e2839de649c7981d3ee742a0b5520ea96ffa872)
lib/thread.c