oracle / dtrace-utils

DTrace-utils contains the DTrace port to Linux
Other
153 stars 20 forks source link

Aggregations are not appropriately cleared #4

Closed euloh closed 1 year ago

euloh commented 3 years ago

Consider:

    BEGIN {
        @s = sum(1);
        printa(@s);
        printa(@s);
        printa(@s);
        exit(0)
    }

One sees the anticipated behavior -- "1" printed three times -- with DTv1. In contrast, with DTv2, the output is

                1
                2
                3

Or, consider

    'tick-5 { @s = sum(1); printa(@s); } tick-1100ms { exit(0) }'
    'tick-2s { @s = sum(1); printa(@s); } tick-11s { exit(0) }'

We would expect the aggregation to increase from 1 to 5, with it being printed five times along the way. The difference is the timing, and output can depend on buffering, aggregation rate, and so on. With DTv1, we observe

                5
                5
                5
                5
                5

("fast" firing rate) and

                1
                2
                3
                4
                5

("slow" firing rate) respectively, both reasonable results. In contrast, with DTv2, we get

                1
                3
                6
               10
               15
euloh commented 3 years ago

With DTv1, aggregations were accumulated in user space. Each printa() would read buffers and add them to the already fetched data.

With DTv2, aggregations are accumulated by the kernel in BPF maps. Each printa() reads the BPF map afresh. It should not add newly read data to older data.

euloh commented 3 years ago

Actually, even just multiple printa() actions are enough to demonstrate the problem.

BEGIN {
    @a = sum(1);
    @b = count();
    @c = sum(1);
    printa(@a);
    printa(@b);
    printa(@c);
   exit(0)
}

This should print 1, 1, 1, as it does with DTv1, but it prints 1, 2, 3 with DTv2. This was causing tst.llquantize_basic.d to fail.

kvanhees commented 1 year ago

Verified as fixed.