On Thu 31-03-11 11:10:00, Ying Han wrote: > On Thu, Mar 31, 2011 at 2:53 AM, Michal Hocko <mhocko@xxxxxxx> wrote: > > On Wed 30-03-11 10:59:21, Ying Han wrote: [...] > > That was my concern so I made that isolation rather opt-in without > > modifying the current reclaim logic too much (there are, of course, > > parts that can be improved). > > So far we are discussing the memory limit only for user pages. Later > we definitely need a kernel memory slab accounting and also for > reclaim. If we put them together, do you still have the concern? Sorry > guess I am just trying to understand the concern w/ example. If we account the kernel memory then it should be less problematic, I guess. [...] > > Lots of groups is really an issue because we can end up in a situation > > when everybody is under the limit while there is not much memory left > > for the kernel. Maybe sum(soft_limit) < kernel_treshold condition would > > solve this. > most of the kernel memory are allocated on behalf of processes in > cgroup. One way of doing that (after having kernel memory accounting) > is to count in kernel memory into usage_in_bytes. So we have the > following: > > 1) limit_in_bytes: cap of memory allocation (user + kernel) for cgroup-A > 2) soft_limit_in_bytes: guarantee of memory allocation (user + > kernel) for cgroup-A > 3) usage_in_bytes: user pages + kernel pages (allocated on behalf of the memcg) > > The above need kernel memory accounting and targeting reclaim. Then we > have sum(soft_limit) < machine capacity. Hope we can talk a bit in the > LSF on this too. Sure. I am looking forward. > >> The later one breaks the isolation. > > > > Sorry, I don't understand. Why would elimination of the global lru > > scanning break isolation? Or am I misreading you? > > Sorry, i meant the other way around. So we agree on this . Makes more sense now ;) Thanks -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>