Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752542AbbG3SK1 (ORCPT ); Thu, 30 Jul 2015 14:10:27 -0400 Received: from mga02.intel.com ([134.134.136.20]:10519 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750937AbbG3SK0 (ORCPT ); Thu, 30 Jul 2015 14:10:26 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,578,1432623600"; d="scan'208";a="739011894" Date: Thu, 30 Jul 2015 11:10:18 -0700 (PDT) From: Vikas Shivappa X-X-Sender: vikas@vshiva-Udesk To: Peter Zijlstra cc: Vikas Shivappa , linux-kernel@vger.kernel.org, vikas.shivappa@intel.com, x86@kernel.org, hpa@zytor.com, tglx@linutronix.de, mingo@kernel.org, tj@kernel.org, matt.fleming@intel.com, will.auld@intel.com, glenn.p.williamson@intel.com, kanaka.d.juvva@intel.com Subject: Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management In-Reply-To: <20150728171748.GV25159@twins.programming.kicks-ass.net> Message-ID: References: <1435789270-27010-1-git-send-email-vikas.shivappa@linux.intel.com> <1435789270-27010-6-git-send-email-vikas.shivappa@linux.intel.com> <20150728171748.GV25159@twins.programming.kicks-ass.net> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1531 Lines: 56 On Tue, 28 Jul 2015, Peter Zijlstra wrote: > On Wed, Jul 01, 2015 at 03:21:06PM -0700, Vikas Shivappa wrote: >> static int __init intel_rdt_late_init(void) >> { >> struct cpuinfo_x86 *c = &boot_cpu_data; >> + static struct clos_cbm_map *ccm; >> + u32 maxid, max_cbm_len; >> + size_t sizeb; > > Why 'sizeb' ? 'size' is still available, right? will fix. int size should be good enough. > >> + int err = 0; >> >> - if (!cpu_has(c, X86_FEATURE_CAT_L3)) >> + if (!cpu_has(c, X86_FEATURE_CAT_L3)) { >> + rdt_root_group.css.ss->disabled = 1; >> return -ENODEV; >> + } >> + maxid = c->x86_cache_max_closid; >> + max_cbm_len = c->x86_cache_max_cbm_len; >> + >> + sizeb = BITS_TO_LONGS(maxid) * sizeof(long); >> + rdtss_info.closmap = kzalloc(sizeb, GFP_KERNEL); >> + if (!rdtss_info.closmap) { >> + err = -ENOMEM; >> + goto out_err; >> + } >> + >> + sizeb = maxid * sizeof(struct clos_cbm_map); >> + ccmap = kzalloc(sizeb, GFP_KERNEL); >> + if (!ccmap) { >> + kfree(rdtss_info.closmap); >> + err = -ENOMEM; >> + goto out_err; >> + } > > What's the expected size of max_closid? iow, how big of an array are you > in fact allocating here? the size of maxclosid value is 16 bits.. For systems with large CPUs this may be more but with EPs have only seen 20-30. Thanks, Vikas > -- 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/