[LTP] [PATCH v2] memory: rewrite memcg_stress_test into C API

[Andrea Cervesato]

Hi Michal,

On Fri Nov 7, 2025 at 11:33 AM CET, Michal Koutný wrote:
> Hi Andrea.
>
> On Thu, Nov 06, 2025 at 09:16:06AM +0100, Andrea Cervesato <andrea.cervesato@suse.de> wrote:
>> From: Andrea Cervesato <andrea.cervesato@suse.com>
>> 
>> This test will stress the cgroup implementation by allocating the whole
>> free system memory inside multiple containers, one page at time.
>> 
>> Signed-off-by: Andrea Cervesato <andrea.cervesato@suse.com>
>> ---
>> The previous test was buggy and up to failures. This new implementation
>> deletes shell script code and the C utility used by it, merging the code
>> into C API libray.
>
> I'm not that familiar with the old test, it talks about stressing
> something but there aren't many assertions where one could check it. It
> likely wanted to exhaust all memory uniformly from multiple cgroups,
> however, I'm not sure whether it captures something realisting or
> reality approaching.
>
> Therefore, I like all the /^-/ lines of your patch :-)
> And I also appreciate that the rewrite with standard routines results
> in overall shorter code.
>
> But you changed this exhaustion attempt by serializing the processes (it
> would only use mem_per_proc /= cgroups_num at likely peak, not all of
> the memory because of serialization AFAICS).

I agree, it was a proposal from Cyril, but it's true that it's not
bringing much stress to the system. Instead, the parallel execution
might be more beneficial in this case and perhaps it would speed up the
test quite a lot.

> That intention could be explained better in the commit message.
>
> (When I think about it, some realistic scenarios would be:
> a) starting lots of containers in parallel (and observing latencies)

How do you observe latencies in this case?

> b) running short-lived jobs repeatedly (and checking that it can run
>    indefinitely/sufficiently long w/out accumulation of any residuals)

I guess you mean to repeat the parallel allocation multiple times for a
certain amount of seconds/minutes, right?

> That'd surely deserve a separate commit from the mere rewrite.
> At it becomes more of a performance test rather than binary/discrete
> verification of behavior.)
>
> Thanks and HTH,
> Michal

Thanks,
-- 
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com