Re: [PATCH RFC 0/4] mm: KUnit tests for the page allocator

[David Hildenbrand <david@redhat.com>]

On 24.02.25 15:47, Brendan Jackman wrote:
> The page allocator does a lot of stuff that is not visible to the user
> in any deterministic way. But this stuff is still important and it would
> be nice to test that behaviour.
> 
> KUnit is a tool for unit-testing kernel-internal APIs. This is an
> attempt to adopt it the page allocator.
> 
> I have been hacking on this as a way to try and test the code I'm
> writing for my ASI page_alloc integration proposal [0]. It's been
> extremely useful to be able to "just call it and see what it does". So I
> wanna gather some feedback on whether this basic idea is of interest
> before I invest too much more time in it.
> 
> You can run these tests like this:
> 
> tools/testing/kunit/kunit.py run \
> 	--arch=x86_64 --kernel_args="movablecore=2G" \
> 	--qemu_args="-m 4G" --kunitconfig mm/.kunitconfig
> 
> Unit-testing code that has mutable global variables can be a pain.
> Unit-testing code with mutable global variables _that can change
> concurrently with the tests_ is basically impossible. So, we need some
> way to isolate an "instance" of the allocator that doesn't refer to any
> such concurrently-mutated state.
> 
> Luckily, the allocator only has one really important global variable:
> node_data. So, the approach here is to carve out a subset of that
> variable which is as isolated as possible from the rest of rthe system,
> which can be used for deterministic testing. This is achieved by crating
> a fake "isolated" node at boot, and plugging in memory at test init
> time.
> 
> This is an RFC and not a PATCH because:
> 
> 1. I have not taken much care to ensure the isolation is complete.
>     There are probably sources of flakiness and nondeterminism in here.
> 
> 2. I suspect the the basic idea might be over-complicated: do we really
>     need memory hotplug here? Do we even need the instance of the
>     allocator we're testing to actual memory behind the pages it's
>     allocating, or could we just hallucinate a new region of vmemmap
>     without any of that awkwardness?
> 
>     One significant downside of relying on memory hotplug is that the
>     test won't run if we can't hotplug anything out. That means you have
>     to fiddle with the platform to even run the tests - see the
>     --kernel_args and --qemu_args I had to add to my kunit.py command
>     above.
> 
>     So yeah, other suggestions welcome.
> 
>     2b. I'm not very confident I'm using the hotplug API properly.

Me neither ;)

Dynamically adding memory to that "fake" node is certainly interesting, 
but which guarantees do we have that some other features (page 
migration, memory offlining, page reporting ...) don't interact in weird 
ways with this "fake" node? Adding special-casing all over the place for 
that feels wrong. I assume this is point 1. you note above.

So I don't quite love the idea on first sight ... but I haven't grasped 
all details of the full picture yet I'm afraid.

-- 
Cheers,

David / dhildenb