On Wed, 5 Jun 2013, Johannes Weiner wrote:
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index ff7b40d..d169a8d 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -187,10 +187,6 @@ struct mem_cgroup_per_node {
> struct mem_cgroup_per_zone zoneinfo[MAX_NR_ZONES];
> };
>
> -struct mem_cgroup_lru_info {
> - struct mem_cgroup_per_node *nodeinfo[0];
> -};
> -
> /*
> * Cgroups above their limits are maintained in a RB-Tree, independent of
> * their hierarchy representation
> @@ -384,14 +380,9 @@ struct mem_cgroup {
> #endif
> /* when kmem shrinkers can sleep but can't proceed due to context */
> struct work_struct kmemcg_shrink_work;
> - /*
> - * Per cgroup active and inactive list, similar to the
> - * per zone LRU lists.
> - *
> - * WARNING: This has to be the last element of the struct. Don't
> - * add new fields after this point.
> - */
> - struct mem_cgroup_lru_info info;
> +
> + struct mem_cgroup_per_node *nodeinfo[0];
> + /* WARNING: nodeinfo has to be the last member here */
Nice cleanup, but would this be better as a flexible array member? It
would have an incomplete type like it should have instead of sizeof
returning 0.
> };
>
> static size_t memcg_size(void)
> @@ -777,7 +768,7 @@ static struct mem_cgroup_per_zone *
> mem_cgroup_zoneinfo(struct mem_cgroup *memcg, int nid, int zid)
> {
> VM_BUG_ON((unsigned)nid >= nr_node_ids);
> - return &memcg->info.nodeinfo[nid]->zoneinfo[zid];
> + return &memcg->nodeinfo[nid]->zoneinfo[zid];
> }
>
> struct cgroup_subsys_state *mem_cgroup_css(struct mem_cgroup *memcg)
> @@ -6595,13 +6586,13 @@ static int alloc_mem_cgroup_per_zone_info(struct
> mem_cgroup *memcg, int node)
> mz->on_tree = false;
> mz->memcg = memcg;
> }
> - memcg->info.nodeinfo[node] = pn;
> + memcg->nodeinfo[node] = pn;
> return 0;
> }
>
> static void free_mem_cgroup_per_zone_info(struct mem_cgroup *memcg, int node)
> {
> - kfree(memcg->info.nodeinfo[node]);
> + kfree(memcg->nodeinfo[node]);
> }
>
> static struct mem_cgroup *mem_cgroup_alloc(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
