From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754907Ab2JFCTb (ORCPT ); Fri, 5 Oct 2012 22:19:31 -0400 Received: from mail-pa0-f46.google.com ([209.85.220.46]:41896 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750773Ab2JFCT3 (ORCPT ); Fri, 5 Oct 2012 22:19:29 -0400 Date: Sat, 6 Oct 2012 11:19:24 +0900 From: Tejun Heo To: Glauber Costa Cc: Mel Gorman , Michal Hocko , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com, devel@openvz.org, linux-mm@kvack.org, Suleiman Souhlal , Frederic Weisbecker , David Rientjes , Johannes Weiner Subject: Re: [PATCH v3 04/13] kmem accounting basic infrastructure Message-ID: <20121006021924.GB2601@localhost> References: <50637298.2090904@parallels.com> <20120927120806.GA29104@dhcp22.suse.cz> <20120927143300.GA4251@mtj.dyndns.org> <20120927144307.GH3429@suse.de> <20120927145802.GC4251@mtj.dyndns.org> <50649B4C.8000208@parallels.com> <20120930082358.GG10383@mtj.dyndns.org> <50695817.2030201@parallels.com> <20121003225458.GE19248@localhost> <506D7922.1050108@parallels.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <506D7922.1050108@parallels.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Glauber. On Thu, Oct 04, 2012 at 03:55:14PM +0400, Glauber Costa wrote: > I don't want to bloat unrelated kmem_cache structures, so I can't embed > a memcg array in there: I would have to have a pointer to a memcg array > that gets assigned at first use. But if we don't want to have a static > number, as you and christoph already frowned upon heavily, we may have > to do that memcg side as well. > > The array gets bigger, though, because it pretty much has to be enough > to accomodate all css_ids. Even now, they are more than the 400 I used > in this patchset. Not allocating all of them at once will lead to more > complication and pointer chasing in here. I don't think it would require more pointer chasing. At the simplest, we can just compare the array size each time. If you wanna be more efficient, all arrays can be kept at the same size and resized when the number of memcgs cross the current number. The only runtime overhead would be one pointer deref which I don't think can be avoided regardless of the indexing direction. Thanks. -- tejun From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx203.postini.com [74.125.245.203]) by kanga.kvack.org (Postfix) with SMTP id 66C896B005A for ; Fri, 5 Oct 2012 22:19:29 -0400 (EDT) Received: by mail-pa0-f41.google.com with SMTP id fa10so2688332pad.14 for ; Fri, 05 Oct 2012 19:19:28 -0700 (PDT) Date: Sat, 6 Oct 2012 11:19:24 +0900 From: Tejun Heo Subject: Re: [PATCH v3 04/13] kmem accounting basic infrastructure Message-ID: <20121006021924.GB2601@localhost> References: <50637298.2090904@parallels.com> <20120927120806.GA29104@dhcp22.suse.cz> <20120927143300.GA4251@mtj.dyndns.org> <20120927144307.GH3429@suse.de> <20120927145802.GC4251@mtj.dyndns.org> <50649B4C.8000208@parallels.com> <20120930082358.GG10383@mtj.dyndns.org> <50695817.2030201@parallels.com> <20121003225458.GE19248@localhost> <506D7922.1050108@parallels.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <506D7922.1050108@parallels.com> Sender: owner-linux-mm@kvack.org List-ID: To: Glauber Costa Cc: Mel Gorman , Michal Hocko , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com, devel@openvz.org, linux-mm@kvack.org, Suleiman Souhlal , Frederic Weisbecker , David Rientjes , Johannes Weiner Hello, Glauber. On Thu, Oct 04, 2012 at 03:55:14PM +0400, Glauber Costa wrote: > I don't want to bloat unrelated kmem_cache structures, so I can't embed > a memcg array in there: I would have to have a pointer to a memcg array > that gets assigned at first use. But if we don't want to have a static > number, as you and christoph already frowned upon heavily, we may have > to do that memcg side as well. > > The array gets bigger, though, because it pretty much has to be enough > to accomodate all css_ids. Even now, they are more than the 400 I used > in this patchset. Not allocating all of them at once will lead to more > complication and pointer chasing in here. I don't think it would require more pointer chasing. At the simplest, we can just compare the array size each time. If you wanna be more efficient, all arrays can be kept at the same size and resized when the number of memcgs cross the current number. The only runtime overhead would be one pointer deref which I don't think can be avoided regardless of the indexing direction. Thanks. -- tejun -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [PATCH v3 04/13] kmem accounting basic infrastructure Date: Sat, 6 Oct 2012 11:19:24 +0900 Message-ID: <20121006021924.GB2601@localhost> References: <50637298.2090904@parallels.com> <20120927120806.GA29104@dhcp22.suse.cz> <20120927143300.GA4251@mtj.dyndns.org> <20120927144307.GH3429@suse.de> <20120927145802.GC4251@mtj.dyndns.org> <50649B4C.8000208@parallels.com> <20120930082358.GG10383@mtj.dyndns.org> <50695817.2030201@parallels.com> <20121003225458.GE19248@localhost> <506D7922.1050108@parallels.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=vUP2y3FZgLEDeUlJCa/AgY0KCRG0ecs/CZuCHL2G6DU=; b=WaoD5Az+y9oe95mV/AsZwvfA228Nm7E7V4IKCJf6xEej4BDBsoMW5jp/j9J0fDRltG W+OxyNq0RrGzQRdeoUJscd/d7OkzFWKMPigogw1fvOavPYmrw7ItAjCXiwsjKLA/dLKX KTZrpLdz1eI8WsIZYW6FWxV0jLBrb/F5oHiAm+0HfLEvSV9E1zLjP29qrUBHXrmhN4sH ks31yJmwklhA3xbACeHdBCTm0gCrMJ5pLyVg7L6VAb+F7sG6Nsx8EpL1luLxWwetK6Dh oJ9FbAwopZuV21A2qGyQPkWz6+eOKw3xmMXlLUlKRVGDm3Q56ypkQHe76xmMcb9XYR88 ij6A== Content-Disposition: inline In-Reply-To: <506D7922.1050108-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Glauber Costa Cc: Mel Gorman , Michal Hocko , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org, devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Suleiman Souhlal , Frederic Weisbecker , David Rientjes , Johannes Weiner Hello, Glauber. On Thu, Oct 04, 2012 at 03:55:14PM +0400, Glauber Costa wrote: > I don't want to bloat unrelated kmem_cache structures, so I can't embed > a memcg array in there: I would have to have a pointer to a memcg array > that gets assigned at first use. But if we don't want to have a static > number, as you and christoph already frowned upon heavily, we may have > to do that memcg side as well. > > The array gets bigger, though, because it pretty much has to be enough > to accomodate all css_ids. Even now, they are more than the 400 I used > in this patchset. Not allocating all of them at once will lead to more > complication and pointer chasing in here. I don't think it would require more pointer chasing. At the simplest, we can just compare the array size each time. If you wanna be more efficient, all arrays can be kept at the same size and resized when the number of memcgs cross the current number. The only runtime overhead would be one pointer deref which I don't think can be avoided regardless of the indexing direction. Thanks. -- tejun