From: Lutz Vieweg <lvml@5t9.de>
To: Balbir Singh <balbir@linux.vnet.ibm.com>,
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-mm@kvack.org, lvml@5t9.de
Subject: "make -j" with memory.(memsw.)limit_in_bytes smaller than required -> livelock, even for unlimited processes
Date: Tue, 21 Jun 2011 16:51:18 +0200 [thread overview]
Message-ID: <4E00AFE6.20302@5t9.de> (raw)
[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]
Dear Memory Ressource Controller maintainers,
by using per-user control groups with a limit on memory (and swap) I am
trying to secure a shared development server against memory exhaustion
by any one single user - as it happened before when somebody imprudently
issued "make -j" (which has the infamous habit to spawn an unlimited
number of processes) on a large software project with many source files.
The memory limitation using control groups works just fine when
only a few processes sum up to a usage that exceeds the limits - the
processes are OOM-killed, then, and the others users are unaffected.
But the original cause, a "make -j" on many source files, leads to
the following ugly symptom:
- make starts numerous (~ 100 < x < 200) gcc processes
- some of those gcc processes get OOM-killed quickly, then
a few more are killed, but with increasing pauses in between
- then after a few seconds, no more gcc processes are killed, but
the "make" process and its childs do not show any progress anymore
- at this time, top indicates 100% "system" CPU usage, mostly by
"[kworker/*]" threads (one per CPU). But processes from other
users, that only require CPU, proceed to run.
- but also at this time, if any other user (who has not exhausted
his memory limits) tries to access any file (at least on /tmp/,
as e.g. gcc does), even a simple "ls /tmp/", this operation
waits forever. (But "iostat" does not indicate any I/O activity.)
- as soon as you press "CTRL-C" to abort the "make -j", everything
goes back to normal, quickly - also the other users' processes proceed.
To reproduce the problem, the attached "Makefile" to a directory
on a filesystem with at least 70MB free space, then
mount -o memory none /cgroup
mkdir /cgroup/test
echo 64M >/cgroup/test/memory.limit_in_bytes
echo 64M >/cgroup/test/memory.memsw.limit_in_bytes
cd /somewhere/with/70mb/free
echo $$ >/cgroup/test/tasks
make sources
make -j compile
Notice that "make sources" will create 200 bogus "*.c" files from
/dev/urandom to make sure that "gcc" will use up some memory.
The "make -j compile" reliably reproduces the above mentioned syndrome,
here.
Please notice that the livelock does happen only with a significant
number of parallel compiler runs - it did e.g. not happen with
only 100 for me, and it also did not happen when I started "make"
with "strace" - so timing seems to be an issue, here.
Thanks for any hints towards a solution of this issue in advance!
Regards,
Lutz Vieweg
[-- Attachment #2: Makefile --]
[-- Type: text/plain, Size: 542 bytes --]
all:
echo "first 'make sources', then 'make -j compile'
N=200
clean:
rm -f file_*.o lib.so
mrproper:
rm -f file_*.c file_*.o lib.so
sources: clean
for (( I=0 ; $$I < $(N) ; I=`expr $$I + 1` )) ; do \
echo $$I; \
echo "char array_$$I [] = " >file_$$I.c ;\
dd if=/dev/urandom bs=256k count=1 | base64 | sed 's/^.*/"\0"/g' >>file_$$I.c ;\
echo ";" >>file_$$I.c ;\
done
OBJ = $(addsuffix .o, $(basename $(notdir $(wildcard file_*.c))))
compile: $(OBJ)
gcc -shared -O3 -o lib.so $(OBJ)
%.o: ./%.c
gcc -O3 -c $< -o $@
next reply other threads:[~2011-06-21 14:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-21 14:51 Lutz Vieweg [this message]
2011-06-21 16:01 ` Ying Han
2011-06-21 16:19 ` Lutz Vieweg
2011-06-21 16:28 ` Ying Han
2011-06-21 16:35 ` Lutz Vieweg
2011-06-22 0:10 ` KAMEZAWA Hiroyuki
2011-06-22 1:06 ` KAMEZAWA Hiroyuki
2011-06-22 10:20 ` KAMEZAWA Hiroyuki
2011-06-22 14:37 ` Michal Hocko
2011-06-22 9:53 ` Lutz Vieweg
2011-06-23 6:13 ` KAMEZAWA Hiroyuki
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=4E00AFE6.20302@5t9.de \
--to=lvml@5t9.de \
--cc=balbir@linux.vnet.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=nishimura@mxp.nes.nec.co.jp \
/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