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> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>