Bug 219358 - test_cpu_read_buf_percent() fails with (expect < 0)
Summary: test_cpu_read_buf_percent() fails with (expect < 0)
Status: NEEDINFO
Alias: None
Product: Tools
Classification: Unclassified
Component: Trace-cmd/Kernelshark (show other bugs)
Hardware: PPC-64 Linux
: P3 normal
Assignee: Default virtual assignee for Trace-cmd and kernelshark
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-10-07 14:39 UTC by Adrien Nader
Modified: 2024-10-07 15:47 UTC (History)
1 user (show)

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Handle large sub-buffer size in percentage test (786 bytes, patch)
2024-10-07 15:32 UTC, Steven Rostedt
Details | Diff

Description Adrien Nader 2024-10-07 14:39:34 UTC
Hi,

When working on the libtracefs 1.8.0/1.8.1 package in Ubuntu, we
observed testsuite failures on ppc64el. I've looked at the first one but
I'm not sure I fully understand the purpose of that test.

The issue is that in test_cpu_read_buf_percent(), expect is negative when
percent = 1.

The test in the following code fails:

    expect = data->nr_subbufs * data->events_per_buf * percent / 100;

    /* Add just under the percent */
    expect -= data->events_per_buf;
    CU_TEST(expect > 0);

I obtained the values used to compute expect:

    buffersize     = 1506304
    bufsize        = 65536
    data_size      = 65520
    events_per_buf = 3276
    nr_subbufs     = 22

    nr_subbufs * events_per_buf * percent / 100
      = 22 * 3276 * 1 / 100 = 720

    expect - events_per_buf
      = 720 - 3276
      = -2556

For reference, the computation with real numbers would give a positive
value:

    nr_subbufs = 1506304 / 65520 = 22.99 // are we unlucky?
    events_per_buf = 65520 / 20 = 3276
    nr_subbufs * events_per_buf * percent / 100 - events_per_buf
      = 22.99 * 3276 - 2556
      = 1802

I expect the check isn't there to test something specific but rather to
ensure the logic of the subsequent code is not derailed by an
unreasonable value.

Is there a specific reason that much is subtracted from expect? Should
this be changed? Should the values be compute slightly differently?

Thanks,

-- 
Adrien
Comment 1 Steven Rostedt 2024-10-07 15:16:08 UTC
The issue is because PowerPC has 64K PAGE_SIZE. The ring buffer sub-buffer size is always at least PAGE_SIZE. That means the "events_per_buf" is going to be quite big as you pointed out. If we did the same logic with the normal 4K PAGE_SIZE we would have:


    buffersize     = 1506304
    bufsize        = 4096
    data_size      = 4080
    events_per_buf = 204
    nr_subbufs     = 369

The algorithm only works when we have more than 100 sub-buffers, but in the case of PowerPC with its large PAGE_SIZE, that's not going to be the case.

Yes, the test is broken here, and you are correct, the check that failed was to make sure the algorithm used was correct (which it is not for PowerPC).

The fix is to account for large sub buffers in the test. I'll fix that sometime in the near future.

Thanks for the report!

-- Steve
Comment 2 Steven Rostedt 2024-10-07 15:32:02 UTC
Created attachment 306981 [details]
Handle large sub-buffer size in percentage test

Create a "min_percent" in the buffer percentage test that will cover at least one sub-buffer size. As PowerPC has 64K PAGE_SIZE which makes the 1 percent less than a sub-buffer page, and the subtraction of one page is going to cause issues.
Comment 3 Steven Rostedt 2024-10-07 15:32:25 UTC
I wrote up a quick fix. Can you test that?
Comment 4 Adrien Nader 2024-10-07 15:47:26 UTC
I'll try to throw that at the CI this evening and I'll pick up a ppc64el machine tomorrow if needed. Thanks a lot!

Note You need to log in before you can comment on or make changes to this bug.