[LTP] [RFC PATCH 4/4] memcg_stress_test.sh: allocate less than CommitLimit bytes

[Michal Hocko]

On Thu 19-05-16 14:56:43, Cyril Hrubis wrote:
> Hi!
> > > Michal is there a way to figure out how much memory should be allocated
> > > and faulted on a system in order to cause some amount of pages to be
> > > swapped back and forth?
> > 
> > that depends on how the memory is used. If it is largerly anonymous then
> > you will get swap out when you hit watermarks.
> 
> The test processes do mmap() with MAP_PRIVATE|MAP_ANONYMOUS so 99% of
> the consumed memory is anonymous.
> 
> If I understand this right watermarks are set to a few megabytes so
> MemFree must get low enough. Isn't there a chance to hit OOM if we try
> to allocate little less than MemFree anway (assuming that we dropped
> caches before we measured MemFree)? There always may be some background
> daemon forking on the system while the test runs which may get use close
> enough to out of memory condition.

As long as there is a reclaimable memory (aka swap space for the
anonymous memory) we shouldn't go OOM.

> Or did I miss something?
> 
> > > What this testcase does it to create a process(es) that allocate memory
> > > and read/write it concurently to stress the system a bit but the
> > > estimate on how much memory it should use is wrong and it causes OOM
> > > when the amount of swap is much less than amount of RAM.
> > 
> > Are we talking about memcg or the global here?
> 
> The test is trying to cause pressure at the global level while the test
> process(es) allocate memory in separate cgroups. No idea how sensible
> this approach is.

Dunno. I fail to see what would be the role of the memcg then.

> > > The original testcase[1] drops caches then runs child(s) to allocate
> > > (in sum) MemFree + SwapFree/2 memory. Each child runs in its own memory
> > > cgroup but the amount of memory was choosen so that the whole system
> > > would be under memory pressure. Does such test even make sense to you?
> > 
> > Well, it depends. It makes sense to see how the global memory pressure
> > gets distributed into two memcgs which are the source of that pressure
> > but I am not really sure how you want to evaluate good vs. bad case as
> > the load will be quite timing sensitive. So the main question would be,
> > what do you expect the test will tell you?
> 
> This is a stress test not a benchmark, so the test genereates pressure
> for an hour and then it reports success if the machine outlived it.

But then why to bother with memcg configuration? I could understand if
you compared the same load with and without memcg in the game but other
than that it sounds like a random bashing of the system.
-- 
Michal Hocko
SUSE Labs