Messages in this thread | | | Date | Wed, 14 Oct 2009 13:51:19 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: Memory overcommit |
| |
On Tue, 13 Oct 2009 19:13:34 +0200 Vedran Furač <vedranf@vedranf.mine.nu> wrote:
> KAMEZAWA Hiroyuki wrote: > > I guess the reason of default value is that the kernel assume > > processes will not always use all mmaped range. There will be unused > > range in process's virtual memory and it can be big. > > > > For example, typical case in a server, when you run multi-thread > > program (like java VM), > > > > - stack per thread - malloc() arena per thread > > > > can makes difference among size-of-mapped-range v.s. used-pages > > bigger. I saw Gigabytes of unused range on ia64 host,...statck size > > was big. > > Yes, I noticed that JVM allocates gigabytes but then uses less than 10% > of that and, as a consequence, eclipse sometimes fails to start although > there's plenty of free memory. So overcommiting is some kind of a > workaround for broken software that allocate not what they need but what > they might need in some rare occurrences. I would rather like fixing > this userland software than risking OOM situations and random killing of > innocent processes. >
In my understanding, mmap() is just for requesting virtual address space. Not for requesting memory in these days.
> > And if strict check(vm.ovecommit_memory=2) is used, mmap() return > > -ENOMEM whenever it hits limit. > > % strace -f -e mmap java -version > [...] > mmap(NULL, 996147200, PROT_READ|PROT_WRITE|PROT_EXEC, > MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot > allocate memory) > > And that should be fine. > It's not fine for me ;)
> > Against random-kill, you may have 2 choices. > > > > 1. use /proc/<pid>/oom_adj 2. use memory cgroup. > > > > Something more easy-to-use method may be appriciated. We have above 2 > > now. > > These are just bad workarounds for bad OOM algorithm. I tested this > little program on multiple systems (including windows) without any > tweaking and linux behavior is, unfortunately *the worst*. :/ > > Yes, they are workaround. You can use /etc/sysctl.conf. But if making it default _now_, many threaded programs will not work.
But I agree, OOM killer should be sophisticated. Please give us a sample program/test case which causes problem. linux-mm@kvack.org may be a better place. lkml has too much traffic.
Regards, -Kame
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |