On Mon, 2 Aug 2010 18:50:11 -0700 (PDT) David Rientjes <rientjes@xxxxxxxxxx> wrote: > On Tue, 3 Aug 2010, KAMEZAWA Hiroyuki wrote: > > > Hmm, then, oom_score shows the values for all limitations in array ? > > > > /proc/pid/oom_score will change if a task's cpuset, memcg, or mempolicy > attachment changes or its mems, nodes, or limit changes because it's a > proportion of available memory. /proc/pid/oom_score_adj stays constant > such that the oom killing priority of that task relative to other tasks > sharing the same constraints and competing for the same memory is the > same. The point is that it doesn't matter how much memory a task has > available, but rather what it's priority is with the tasks that compete > with it for memory. > > You could, of course, do some simple arithmetic to write a memory quantity > to oom_score_adj if you really wanted to, but that would force the user to > recalculate the value anytime the task's cpuset, mempolicy, or memcg > changes. > My concern is this may corrupt LXC and google's oom_adj system, expecially when cpuset is used. > > > > Usual disto alreay enables it. > > > > > > > > > > Yes, I'm well aware of my 40MB of lost memory on my laptop :) > > > > > Very sorry ;) > > But it's required to track memory usage from init... > > > > Memcg comes with a cost of ~1% of system memory on x86 since > struct page_cgroup is ~1% of a 4K page. That means if we were to deploy > memcg on all of our servers and the number of jobs we can run is > constrained only by memory, it's equivalent to losing ~1% of our servers. > That, for us, is very large. > Google can disable it ;) > This is a different topic entirely, but it's a very significant > disadvantage and enough that most people who care about oom killing > prioritization aren't going to wany to incur such an overhead by enabling > memcg or setting up individual memcg for each and every job, because that > requires specific knowledge of all those jobs. > > I'm not by any means proposing oom_score_adj as being very popular for the > usual desktop environments :) > libcgroup will help. Bye. -Kame -- 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>