On Wed, Jun 08, 2011 at 10:54:00AM +0200, Johannes Weiner wrote: > > Wouldn't it be simpler if we always have a stub mem_cgroup_per_zone > > structure even for non-memcg kernels, and always operate on a > > single instance per node of those for non-memcg kernels? In effect the > > lruvec almost is something like that, just adding another layer of > > abstraction. > > I assume you meant 'single instance per zone'; the lruvec is this. Yes, sorry. > It > exists per zone and per mem_cgroup_per_zone so there is no difference > between memcg kernels and non-memcg ones in generic code. But maybe > you really meant 'node' and I just don't get it? Care to elaborate a > bit more? My suggestion was to not bother with adding the new lruvec concept, but make sure we always have sturct mem_cgroup_per_zone around even for non-memcg kernel, thus making the code even more similar for using cgroups or not, and avoiding to keep the superflous lruvec in the zone around for the cgroup case. Basically always keeping a minimal stub memcg infrastructure around. This is really just from the top of my head, so it might not actually be feasily, but it's similar to how we do things elsewhere in the kernel. -- 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>