mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Steven J. Magnani" <steve@digidescorp.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-mm@kvack.org, balbir@linux.vnet.ibm.com,
	dhowells@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3] nommu: add anonymous page memcg accounting
Date: Fri, 22 Oct 2010 08:26:08 -0500	[thread overview]
Message-ID: <1287753968.2589.58.camel@iscandar.digidescorp.com> (raw)
In-Reply-To: <20101022122010.793bebac.kamezawa.hiroyu@jp.fujitsu.com>

On Fri, 2010-10-22 at 12:20 +0900, KAMEZAWA Hiroyuki wrote:
> BTW, have you tried oom_notifier+NOMMU memory limit oom-killer ?
> It may be a chance to implement a custom OOM-Killer in userland on
> EMBEDED systems.

No - for what I need (simple sandboxing) just running my 'problem'
process in a memory cgroup is sufficient. I might even be able to get
away with oom_kill_allocating_task and no cgroup, but since that would
allow dosfsck to run the system completely out of memory there's no
guarantee that it would be the one that pushes the system over the edge.

What do you mean by "NOMMU memory limit"? (Is there some other way to
achieve the same functionality?)

I looked into David's initial suggestion of using ulimit to create a
sandbox but it seems that nommu.c doesn't respect RLIMIT_AS. When I can
find some time I'll try to cook up a patch for that.

Also it seems that nommu.c doesn't ever decrement mm->total_vm, which if
I'm reading the code correctly (before the 2.6.36 OOM-killer rewrite)
could throw off badness calculations for processes that do lots of
malloc/free operations. In 2.6.36 it doesn't look to me like this would
have any ill effects.

Thanks for all the feedback. I fully agree that maintenance should be a
strong consideration when merging new code.

Regards,
------------------------------------------------------------------------
 Steven J. Magnani               "I claim this network for MARS!
 www.digidescorp.com              Earthling, return my space modulator!"

 #include <standard.disclaimer>



  reply	other threads:[~2010-10-22 13:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-21 12:28 Steven J. Magnani
2010-10-22  3:20 ` KAMEZAWA Hiroyuki
2010-10-22 13:26   ` Steven J. Magnani [this message]
2010-10-25  0:13     ` KAMEZAWA Hiroyuki
2010-10-22  3:53 ` Balbir Singh
2010-10-22  4:34   ` 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=1287753968.2589.58.camel@iscandar.digidescorp.com \
    --to=steve@digidescorp.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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

all inboxes | Powered by JetHome®