Re: [PATCH bpf-next 0/4] selftests/bpf: Fix a few test failures with arm64 64KB page

[Ihor Solodrai <ihor.solodrai@linux.dev>]

On 6/6/25 9:57 AM, Andrii Nakryiko wrote:
> On Fri, Jun 6, 2025 at 9:49 AM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>> On 6/6/25 9:43 AM, Yonghong Song wrote:
>>>
>>>
>>> On 6/6/25 9:30 AM, Andrii Nakryiko wrote:
>>>> On Thu, Jun 5, 2025 at 8:23 PM Yonghong Song <yonghong.song@linux.dev>
>>>> wrote:
>>>>> My local arm64 host has 64KB page size and the VM to run test_progs
>>>>> also has 64KB page size. There are a few self tests assuming 4KB page
>>>>> and hence failed in my envorinment. Patch 1 tries to reduce long assert
>>>> typo: environment
>>>>
>>>>> logs when tail failed. Patches 2-4 fixed three selftest failures.
>>>> How come our BPF CI doesn't catch this on aarch64?.. Ihor, any thoughts?
>>>
>>> In CI for aarch64, the page size is 4KB. For example, for this link:
>>>
>>> https://github.com/kernel-patches/bpf/actions/runs/15482212552/
>>> job/43590176563?pr=9053
>>>
>>> Find the kconfig, and we have
>>>
>>>     CONFIG_ARM64_4K_PAGES=y
>>>     # CONFIG_ARM64_16K_PAGES is not set
>>>     # CONFIG_ARM64_64K_PAGES is not set
>>>
>>> and for 4K page, all these tests are fine, but not for 64K page.
>>
>> Ah right, I just realized the host pagesize doesn't matter, the kernel
>> we are running tests against needs to be re-compiled with the right
>> config.
>>
>> If this is important to test on CI, it can be another matrix dimension
>> with customized kconfig. Do we want to do that?
>>
> 
> Can we just use 64KB page size for aarch64 (no 4KB variant for arm64)?

We certainly can, but *not* testing 4k pages on any arch seems like a
bad idea to me.

If we think a step further, there are many permutations of important
configs that we do not test. And it's impractical to test *everything*
for each pending patch.

What we could do is split BPF CI into two domains:
* test most important configurations on every patch like we do now
* test other config permutations on base branches (bpf-next, bpf) 
*sometimes*

We have reserved hardware that is often idle when there is low
activity on the list, and it could be used to run other things:
older/newer compilers, different page sizes, particular kconfigs etc.

This way we would catch problems earlier without overloading/expanding
the CI infra.

It's an effort to setup of course, but that's how I would approach it
if we're serious about testing uncommon things.


>>
>>>
>>>
>>>>
>>>>> Yonghong Song (4):
>>>>>     selftests/bpf: Reduce test_xdp_adjust_frags_tail_grow logs
>>>>>     selftests/bpf: Fix bpf_mod_race test failure with arm64 64KB page
>>>>> size
>>>>>     selftests/bpf: Fix ringbuf/ringbuf_write test failure with arm64 64KB
>>>>>       page size
>>>>>     selftests/bpf: Fix a user_ringbuf failure with arm64 64KB page size
>>>>>
>>>>>    .../selftests/bpf/prog_tests/bpf_mod_race.c    |  2 +-
>>>>>    .../testing/selftests/bpf/prog_tests/ringbuf.c |  5 +++--
>>>>>    .../selftests/bpf/prog_tests/user_ringbuf.c    |  6 ++++--
>>>>>    .../selftests/bpf/prog_tests/xdp_adjust_tail.c | 18 ++++++++++++------
>>>>>    .../selftests/bpf/progs/test_ringbuf_write.c   |  5 +++--
>>>>>    5 files changed, 23 insertions(+), 13 deletions(-)
>>>>>
>>>>> --
>>>>> 2.47.1
>>>>>
>>>
>>