Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753069Ab1FIJXk (ORCPT ); Thu, 9 Jun 2011 05:23:40 -0400 Received: from 173-166-109-252-newengland.hfc.comcastbusiness.net ([173.166.109.252]:47413 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752117Ab1FIJXg (ORCPT ); Thu, 9 Jun 2011 05:23:36 -0400 Date: Thu, 9 Jun 2011 05:23:10 -0400 From: Christoph Hellwig To: Johannes Weiner Cc: Christoph Hellwig , KAMEZAWA Hiroyuki , Daisuke Nishimura , Balbir Singh , Ying Han , Michal Hocko , Andrew Morton , Rik van Riel , Minchan Kim , KOSAKI Motohiro , Mel Gorman , Greg Thelen , Michel Lespinasse , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [patch 8/8] mm: make per-memcg lru lists exclusive Message-ID: <20110609092310.GA10741@infradead.org> References: <1306909519-7286-1-git-send-email-hannes@cmpxchg.org> <1306909519-7286-9-git-send-email-hannes@cmpxchg.org> <20110607124213.GB18571@infradead.org> <20110608085400.GA17886@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110608085400.GA17886@cmpxchg.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1453 Lines: 33 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/