]> git.puffer.fish Git - matthieu/frr.git/commit
lib: Fix FreeBSD clock_gettime(CLOCK_THREAD_CPUTIME_ID,..) going backwards
authorDonald Sharp <sharpd@nvidia.com>
Tue, 1 Mar 2022 14:02:33 +0000 (09:02 -0500)
committerDonald Sharp <sharpd@nvidia.com>
Tue, 1 Mar 2022 14:08:32 +0000 (09:08 -0500)
commit4e2839de649c7981d3ee742a0b5520ea96ffa872
treef0b9d26638df12c525adf7c0ba1678e75f904de8
parent2821405a69838f8c144620a9a59aff56d51bd761
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>
lib/thread.c