Re: time(1) reporting corrupted system time
Mateusz Guzik wrote: > Hi, I failed to find a follow up to this. > > I see someone gave the you the fix for corrupted time accounting. > Did you get around to finding the offending commit? For the corrupted system time, I believe the offending commit was kern_resource.c 1.180, and the fix was 1.182. As for the increased system time taken by release builds, it has happened in multiple steps. I have bisected the largest increases, but analyzing and writing up the results for current-users is still on my "to do" list. -- Andreas Gustafsson, g...@gson.org
Re: time(1) reporting corrupted system time
On 9/29/19, Andreas Gustafsson wrote: > Hi all, > > I'm trying to run a bisection to determine why builds hosted on recent > versions of NetBSD seem to be taking significantly more system time > than they used to, building the same thing. > > My efforts are hampered by time(1) reporting corrupted system times on > certain past versions of -current: > > 2017.01.01.03.06.06/build_8.log: 3562.32 real 15806.10 user > 4893.62 sys > 2018.05.21.10.28.13/build_8.log: 4250.22 real 16835.23 user > 608742554440425.55 sys > 2019.01.30.20.20.36/build_8.log: 4228.25 real 16801.48 user > 700976274808841.24 sys > 2019.09.27.08.57.12/build_8.log: 4488.49 real 16670.79 user > 9279.25 sys > > Does anyone happen to know which commits caused and/or fixed this? > This information could save me a couple of days of bisection run time. Hi, I failed to find a follow up to this. I see someone gave the you the fix for corrupted time accounting. Did you get around to finding the offending commit? -- Mateusz Guzik
Re: time(1) reporting corrupted system time
Michael van Elst wrote: > First there was a change to precent that user/system time are decreasing > in kern-resource.c 1.180. But it shouldn't be related to negative numbers. > > Additionally a possible underflow of user/system time was fixed in > kern_resource.c 1.182. This prevents negative numbers, but IIRC this > would only happen for very small values, not when values already > accumulated to a few thousand seconds. Thanks. I think what happened is that 1.180 caused the bug, and 1.182 fixed it. In any case, I think I now have what I need to back-port the fix and bisect the other bug. -- Andreas Gustafsson, g...@gson.org
time(1) reporting corrupted system time
Hi all, I'm trying to run a bisection to determine why builds hosted on recent versions of NetBSD seem to be taking significantly more system time than they used to, building the same thing. My efforts are hampered by time(1) reporting corrupted system times on certain past versions of -current: 2017.01.01.03.06.06/build_8.log: 3562.32 real 15806.10 user 4893.62 sys 2018.05.21.10.28.13/build_8.log: 4250.22 real 16835.23 user 608742554440425.55 sys 2019.01.30.20.20.36/build_8.log: 4228.25 real 16801.48 user 700976274808841.24 sys 2019.09.27.08.57.12/build_8.log: 4488.49 real 16670.79 user 9279.25 sys Does anyone happen to know which commits caused and/or fixed this? This information could save me a couple of days of bisection run time. -- Andreas Gustafsson, g...@gson.org
