Process accounting/timing has broken recently
Garrett Cooper
gcooper at FreeBSD.org
Mon Dec 6 06:24:15 UTC 2010
On Sun, Dec 5, 2010 at 10:22 PM, Julian Elischer <julian at freebsd.org> wrote:
> On 12/5/10 10:19 PM, Garrett Cooper wrote:
>>
>> On Sun, Dec 5, 2010 at 10:12 PM, Steve Kargl
>> <sgk at troutmask.apl.washington.edu> wrote:
>>>
>>> On Sun, Dec 05, 2010 at 04:00:32PM -0800, Julian Elischer wrote:
>>>>
>>>> On 12/5/10 3:18 PM, Steve Kargl wrote:
>>>>>
>>>>> Sometime in the last 7-10 days, some one made a
>>>>> change that has broken process accounting/timing.
>>>>>
>>>>> laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 )
>>>>> foreach? time ./testf
>>>>> foreach? end
>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =
>>>>> 1.067100e-04
>>>>> 69.55 real 38.39 user 30.94 sys
>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =
>>>>> 1.067100e-04
>>>>> 68.82 real 40.95 user 27.60 sys
>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =
>>>>> 1.067100e-04
>>>>> 69.14 real 38.90 user 30.02 sys
>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =
>>>>> 1.067100e-04
>>>>> 68.79 real 40.59 user 27.99 sys
>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =
>>>>> 1.067100e-04
>>>>> 68.93 real 39.76 user 28.96 sys
>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =
>>>>> 1.067100e-04
>>>>> 68.71 real 41.21 user 27.29 sys
>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =
>>>>> 1.067100e-04
>>>>> 69.05 real 39.68 user 29.15 sys
>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =
>>>>> 1.067100e-04
>>>>> 68.99 real 39.98 user 28.80 sys
>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =
>>>>> 1.067100e-04
>>>>> 69.02 real 39.64 user 29.16 sys
>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =
>>>>> 1.067100e-04
>>>>> 69.38 real 37.49 user 31.67 sys
>>>>>
>>>>> testf is a numerically intensive program that tests the
>>>>> accuracy of expf() in a tight loop. User time varies
>>>>> by ~3 seconds on my lightly loaded 2 GHz core2 duo processor.
>>>>> I'm fairly certain that the code does not suddenly grow/loose
>>>>> 6 GFLOP of operations.
>>>>>
>>>> I know it's a lot to ask but it may be something that you can help
>>>> with if you
>>>> had the time to triangulate in on the change that did it..
>>>> I presume that since you are an "old hand" you can check out sources
>>>> at different revisions..
>>>
>>> I was hoping that someone (possibly the person responsible) would
>>> recognize the symptoms and recommend a revision or two to revert.
>>> Otherwise, doing a binary search will take some time in that it
>>> takes 4+ hours for a buildworld/kernel cycle on my laptop.
>>
>> If you can provide the source for the application you're running
>> above and instructions on how to compile it, I can at least give you a
>> bit of a head start :).
>> Thanks,
>> -Garrett
>>
> plus which probably just
> `cd /sys/amd64/conf config GENERIC;cd ../compile/GENERIC; make kernel`
> would be enough...
But couldn't it be libthr changes? There have been a handful of
those that have been committed recently by davidxu.
HTH,
-Garrett
More information about the freebsd-current
mailing list