Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp4698105pxb; Tue, 31 Aug 2021 11:04:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhmld/1GnFY3MjX9BzM6tiemOdduoJjcmv2RI9zAqRMkxFfX9uxgfzM140lf07yo/7LbEc X-Received: by 2002:a17:906:49d5:: with SMTP id w21mr31717498ejv.30.1630433072155; Tue, 31 Aug 2021 11:04:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630433072; cv=none; d=google.com; s=arc-20160816; b=krinFajtt1Y10bi+DWtKrLetsUEzmF3aW/R+t32TIR6+GKxN0NiyMN6mNbPGTio5NI YqmylFkF1w2nAd7UXuU1uHOeRfwBiUrKNmk7X6Y6UPPtZPdT5boyYOcUtbCrBvDj7pVz 0gcGse2sU1DpkEzEyDGFOs8U0VdVFphChFEvxhAiAP9Hy0YI81xH4VvR/iV9qRmPU/WC KLBNWtWejIacvKiCLfkmIAf/uJ5Qvhtl+A/t2Oro4xRHH+BnMGkYtf6BR3d6EIucRVYW 2tMryyqonJhC/EZc1u/3vAR6n0Bqa8hEow56qOA6JKCDN95oGGu7kh5GsjXlrVXAlAsO BMMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=fUxON7DQfBkwhkkBuiTN0hZCEXHKQEFYBG5xz8Rj/mE=; b=NCmhMLmiz3xbHh+fpHVLIf0iSHotfk11EQhUFlZR+Vh1GK8EMLWNNvqDKRKSLQbPOz UwyNnx41/GbStqWphXxHHGn02BZB41kJmnF3OBZ54/jlB96pigQ3SYrYS1noC2RR7Db/ EfVGUbWGEnRD+aZw8lPn+jO8uKZOaeOZHyZQaaPYmoYX9m5IXMwm+gCwpqwUexDL2KWf pud8TT0gqa2HCc+h3MIF3S9pxfIqSeNFR3KHVkeux6JzS1lGM5jRrppw0R6PKPBQwIfv JZUhoE3rFTabzZvkx3o8dW8utz8G5WRsminYA9t4MADVnmlKQlCmFg6yognyTKTKZ62j 0zDQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m1si11881895ejj.616.2021.08.31.11.04.08; Tue, 31 Aug 2021 11:04:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239948AbhHaQ0J (ORCPT + 99 others); Tue, 31 Aug 2021 12:26:09 -0400 Received: from foss.arm.com ([217.140.110.172]:56420 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239964AbhHaQ0G (ORCPT ); Tue, 31 Aug 2021 12:26:06 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 69AD06D; Tue, 31 Aug 2021 09:25:10 -0700 (PDT) Received: from [192.168.0.14] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 417CF3F766; Tue, 31 Aug 2021 09:25:08 -0700 (PDT) Subject: Re: [PATCH v1 12/20] x86/recstrl: Add per-rmid arch private storage for overflow and chunks To: Jamie Iles Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Fenghua Yu , Reinette Chatre , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Babu Moger , shameerali.kolothum.thodi@huawei.com, D Scott Phillips OS , lcherian@marvell.com, bobo.shaobowang@huawei.com References: <20210729223610.29373-1-james.morse@arm.com> <20210729223610.29373-13-james.morse@arm.com> From: James Morse Message-ID: <5caa74a5-a73d-a5ce-9169-396ad3727386@arm.com> Date: Tue, 31 Aug 2021 17:25:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jamie, On 11/08/2021 18:14, Jamie Iles wrote: > On Thu, Jul 29, 2021 at 10:36:02PM +0000, James Morse wrote: >> resctrl_arch_rmid_read() is intended as the function that an >> architecture agnostic resctrl filesystem driver can use to >> read a value in bytes from a counter. Currently the function returns >> the mbm values in chunks directly from hardware. For bandwidth >> counters the resctrl filesystem provides the number of bytes >> ever seen. Internally mba_sc uses a second prev_bw_msr to calculate >> the bytes read since the last mba_sc invocation. >> >> MPAM's scaling of counters can be changed at runtime, reducing the >> resolution but increasing the range. When this is changed the prev_msr >> values need to be converted by the architecture code. >> >> Add storage for per-rmid private storage. The prev_msr and chunks >> values will move here to allow resctrl_arch_rmid_read() to always >> return the number of bytes read by this counter. >> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c >> index 8a3c13c6c19f..27c93d12ca27 100644 >> --- a/arch/x86/kernel/cpu/resctrl/core.c >> +++ b/arch/x86/kernel/cpu/resctrl/core.c >> @@ -432,6 +432,28 @@ static int domain_setup_ctrlval(struct rdt_resource *r, struct rdt_domain *d) >> +static int arch_domain_mbm_alloc(u32 num_rmid, struct rdt_hw_domain *hw_dom) >> +{ >> + size_t tsize; >> + >> + if (is_mbm_total_enabled()) { >> + tsize = sizeof(*hw_dom->arch_mbm_total); >> + hw_dom->arch_mbm_total = kcalloc(num_rmid, tsize, GFP_KERNEL); >> + if (!hw_dom->arch_mbm_total) >> + return -ENOMEM; >> + } >> + if (is_mbm_local_enabled()) { >> + tsize = sizeof(*hw_dom->arch_mbm_local); >> + hw_dom->arch_mbm_local = kcalloc(num_rmid, tsize, GFP_KERNEL); >> + if (!hw_dom->arch_mbm_local) { >> + kfree(hw_dom->arch_mbm_total); >> + return -ENOMEM; >> + } >> + } >> + >> + return 0; >> +} >> + >> @@ -481,6 +503,11 @@ static void domain_add_cpu(int cpu, struct rdt_resource *r) >> return; >> } >> >> + if (r->mon_capable && arch_domain_mbm_alloc(r->num_rmid, hw_dom)) { >> + kfree(d); > > Does this error path and subsequent ones in domain_add_cpu also need to > undo the allocations from arch_domain_mbm_alloc? This one needs to free the ctrl_val array, as does the path from resctrl_online_domain(). Yes, resctrl_online_domain() needs to free the two mbm arrays. Thanks! Its probably cleanest to add some helper in patch 3 that kfree()s anything that might have been allocated, and add-to/remote-from that over time. The root structure is kzalloc()d , so shouldn't need an elaborate and verbose unwind/goto-nest. Thanks, James