From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Thelen Subject: Re: [PATCH v2] memcg: reduce the size of struct memcg 244-fold. Date: Fri, 25 Jan 2013 09:14:09 -0800 Message-ID: References: <1359009996-5350-1-git-send-email-glommer@parallels.com> <20130124155105.85dae9d9.akpm@linux-foundation.org> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=u01sOKMeE/pw7DpPfKNz/KDdhPZycMXHfnHXnZl3xUQ=; b=LeWpeoIgekn8MT7GZuzCwK0/OeZy24fIQCq+SNIrYIF06/NEIRI9tXNz1dJBHwED+V NBcMOAqIoSXuTtdsL6vLJRUKlZMVLcVC3hCvxht+ENRxTIJNYrL93W0tp+/6VPkwPvNq 8UMExAGBkAvwE1QUjAo1QScgu8yTPeB4eYcX4el2Nqxbe3ateFAvoQab+b64n798R7lp +hl2aGNF2+wz5DOlyh8q1uiy6UUYlV214H/AnkdWH06jXZn1e9JBgCxbtqm4AcMUGmU5 s492h2Q7whXlsEQY9LiC+yP0EFmMpYB8UHGg113M+Y/I5yrx0D0AwzrsQfm2GlLy0TLg IwYQ== In-Reply-To: <20130124155105.85dae9d9.akpm@linux-foundation.org> (Andrew Morton's message of "Thu, 24 Jan 2013 15:51:05 -0800") Sender: owner-linux-mm@kvack.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Andrew Morton Cc: Glauber Costa , linux-mm@kvack.org, cgroups@vger.kernel.org, Michal Hocko , Kamezawa Hiroyuki , Johannes Weiner , Hugh Dickins , Ying Han , Mel Gorman , Rik van Riel On Thu, Jan 24 2013, Andrew Morton wrote: > On Wed, 23 Jan 2013 23:50:31 -0800 > Greg Thelen wrote: > >> > --- a/mm/memcontrol.c >> > +++ b/mm/memcontrol.c >> > @@ -172,7 +172,7 @@ struct mem_cgroup_per_node { >> > }; >> > >> > struct mem_cgroup_lru_info { >> > - struct mem_cgroup_per_node *nodeinfo[MAX_NUMNODES]; >> > + struct mem_cgroup_per_node *nodeinfo[0]; >> >> It seems like a VM_BUG_ON() in mem_cgroup_zoneinfo() asserting that the >> nid index is less than nr_node_ids would be good at catching illegal >> indexes. I don't see any illegal indexes in your patch, but I fear that >> someday a MAX_NUMNODES based for() loop might sneak in. > > Can't hurt ;) > >> Tangential question: why use inline here? I figure that modern >> compilers are good at making inlining decisions. > > And that'll save some disk space. > > This? Yup, that looks good to me. Acked-by: Greg Thelen > --- a/mm/memcontrol.c~memcg-reduce-the-size-of-struct-memcg-244-fold-fix > +++ a/mm/memcontrol.c > @@ -381,7 +381,7 @@ enum { > ((1 << KMEM_ACCOUNTED_ACTIVE) | (1 << KMEM_ACCOUNTED_ACTIVATED)) > > #ifdef CONFIG_MEMCG_KMEM > -static inline void memcg_kmem_set_active(struct mem_cgroup *memcg) > +static void memcg_kmem_set_active(struct mem_cgroup *memcg) > { > set_bit(KMEM_ACCOUNTED_ACTIVE, &memcg->kmem_account_flags); > } > @@ -645,6 +645,7 @@ static void drain_all_stock_async(struct > 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]; > } > > _ > > Glauber, could you please cc me on patches more often? It's a bit of a > pita having to go back to the mailing list to see if there has been > more dicussion and I may end up missing late review comments and acks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org