On Tue 05-03-13 17:10:57, Glauber Costa wrote: > If we are not using memcg, there is no reason why we should allocate > this structure, that will be a memory waste at best. We can do better > at least in the sparsemem case, and allocate it when the first cgroup > is requested. It should now not panic on failure, and we have to handle > this right. lookup_page_cgroup needs a special handling as well. Callers are not prepared to get NULL and the current code would even explode with !CONFIG_DEBUG_VM. Anyway, agreed with what Kame said. This is really hard to read. Would it be possible to split it up somehow - sorry for not being more helpful here... > flatmem case is a bit more complicated, so that one is left out for > the moment. > > Signed-off-by: Glauber Costa <glommer@xxxxxxxxxxxxx> > CC: Michal Hocko <mhocko@xxxxxxx> > CC: Kamezawa Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> > CC: Johannes Weiner <hannes@xxxxxxxxxxx> > CC: Mel Gorman <mgorman@xxxxxxx> > CC: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > --- > include/linux/page_cgroup.h | 28 +++++---- > init/main.c | 2 - > mm/memcontrol.c | 3 +- > mm/page_cgroup.c | 150 ++++++++++++++++++++++++-------------------- > 4 files changed, 99 insertions(+), 84 deletions(-) > [...] -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>