All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lutz Vieweg <lvml@5t9.de>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>,
	Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
	linux-mm@kvack.org
Subject: Re: "make -j" with memory.(memsw.)limit_in_bytes smaller than required -> livelock,  even for unlimited processes
Date: Wed, 22 Jun 2011 11:53:10 +0200	[thread overview]
Message-ID: <4E01BB86.5010708@5t9.de> (raw)
In-Reply-To: <20110622091018.16c14c78.kamezawa.hiroyu@jp.fujitsu.com>

On 06/22/2011 02:10 AM, KAMEZAWA Hiroyuki wrote:

> This is a famous fork-bomb problem.

Well, the classical fork-bomb would probably try to spawn an infinite
amount of processes, while the number of processes spawned by "make -j"
is limited to the amount of source files (200 in my reproduction Makefile)
and "make" will not restart any processes that got OOM-killed, so it
should terminate after a (not really long) while.

> Don't you use your test set under some cpu cgroup ?

I use the "cpu" controller, too, but haven't seen adverse
effects from doing that so far.
Even in the situation of the livelock I reported, processes
of other users that do not try I/O get their fair share
of CPU time.


> Then, you can stop oom-kill by echo 1>  .../memory.oom_control.
> All processes under memcg will be blocked. you can kill all process under memcg
> by you hands.

Well, but automatic OOM-killing of the processes of the memory hog was exactly
the desired behaviour I was looking for :-)


>>    echo 64M>/cgroup/test/memory.limit_in_bytes
>>    echo 64M>/cgroup/test/memory.memsw.limit_in_bytes
>
> 64M is crazy small limit for make -j , I use 300M for my test...

Just as well, in our real-world use case, the limits are set both
to 16G (which still isn't enough for a "make -j" on our huge source tree),
I intentionally set a rather low limit for the test-Makefile because
I wanted to spare others from first having to write 16G of bogus
source-files to their local storage before the symptom can be reproduced.


> and plesse see what hapeens when
>
>   echo 1>  /memory.oom_control

When I do this before the "make -j", the make childs are stopped,
processes of other users proceed normally.

But of course this will let the user who did the "make -j" assume
the machine is just busy with the compilation, instead of telling
him "you used too much memory".
And further processes started by the same users will mysteriously
stop, too...


> Then, waiting for some page bit...I/O of libc mapped pages ?
>
> Hmm. it seems buggy behavior. Okay, I'll dig this.

Thanks a lot for investigating!

Regards,

Lutz Vieweg


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2011-06-22  9:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-21 14:51 "make -j" with memory.(memsw.)limit_in_bytes smaller than required -> livelock, even for unlimited processes Lutz Vieweg
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 [this message]
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=4E01BB86.5010708@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.