From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [RFC PATCH 4/4] memcg_stress_test.sh: allocate less than CommitLimit bytes
Date: Thu, 19 May 2016 14:56:43 +0200 [thread overview]
Message-ID: <20160519125643.GB29601@rei.lan> (raw)
In-Reply-To: <20160519091721.GH26110@dhcp22.suse.cz>
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.
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.
> > 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.
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2016-05-19 12:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-22 15:23 [LTP] [PATCH 1/4] memcg_process_stress: cleanup Stanislav Kholmanskikh
2016-04-22 15:23 ` [LTP] [PATCH 2/4] memcg_process_stress: allocate memory not in the signal handler Stanislav Kholmanskikh
2016-04-22 15:23 ` [LTP] [PATCH 3/4] memcg_stress_test.sh: rewrite Stanislav Kholmanskikh
2016-04-22 15:23 ` [LTP] [RFC PATCH 4/4] memcg_stress_test.sh: allocate less than CommitLimit bytes Stanislav Kholmanskikh
2016-05-12 13:42 ` Cyril Hrubis
2016-05-17 12:52 ` Stanislav Kholmanskikh
2016-05-17 13:02 ` Stanislav Kholmanskikh
2016-05-18 14:39 ` Cyril Hrubis
2016-05-18 17:29 ` Stanislav Kholmanskikh
2016-05-19 13:38 ` Cyril Hrubis
2016-05-23 11:12 ` Stanislav Kholmanskikh
2016-05-24 16:46 ` Cyril Hrubis
2016-05-19 9:17 ` Michal Hocko
2016-05-19 12:56 ` Cyril Hrubis [this message]
2016-05-19 19:21 ` Michal Hocko
2016-05-24 16:21 ` Cyril Hrubis
2016-05-11 15:01 ` [LTP] [PATCH 3/4] memcg_stress_test.sh: rewrite Cyril Hrubis
2016-05-11 14:39 ` [LTP] [PATCH 2/4] memcg_process_stress: allocate memory not in the signal handler Cyril Hrubis
2016-05-12 11:09 ` Stanislav Kholmanskikh
2016-05-12 11:26 ` Cyril Hrubis
2016-05-11 14:16 ` [LTP] [PATCH 1/4] memcg_process_stress: cleanup Cyril Hrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160519125643.GB29601@rei.lan \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox