Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3052924pxj; Mon, 14 Jun 2021 13:15:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxGnRiloiWd2C37U7V4rRCd90YErcK7nrT9PG5pvjoXZz13RbqrcHT7oasMKxGmNT72PeX9 X-Received: by 2002:aa7:d755:: with SMTP id a21mr19323362eds.146.1623701741338; Mon, 14 Jun 2021 13:15:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623701741; cv=none; d=google.com; s=arc-20160816; b=YnS8KeN4rHy4asDjVvS+XP2JtXiiKYV0bmxwl7Zhj/49YbkwzPXCyWSrOLWRYbxlry /5m0Y0q2EMcgDS+JYHw/A/UJBBlcGAXpfyMRMnth1FtglbKd411Oj80po6Hi36FEtBi2 NEWFpKjkAjN6vLh133SWYfKBd6fe+g3ZS8U00GTyFknGh9MvqPPISAjPX6EWT+s7jxYt QjmiGC7GkM2gx4TQHViM8EVCPM+CPcSCB+Nis0Cpzym0A45C5TldV8mUngLZEGPGZiDE f0KHHkg9eZiIvkWcBKBGUKtFpT7MHCCycoetadzt0NWZVUuLcvJCcojzjhyaZ3hVkcrv YmuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=KpWnqJaxfq/iUFZs0fqJzZFxpi08GD6RyvwXC28UfoA=; b=M6tUYn8kiiSCrSjLg9sMgmutdMPI6yAhrtCZtEUkXCFHJbVFTZ4AXtlYwlrofIgu2l KjW4KgCQS1hnvsdYfgvnUCgO0OTbID+x0UyNAJGDpw6wPJV+TQtiV2rs4LNEEdZvdtgx likNmK02yrOr6whlmEC8Ujnwrq85Er/ejPRhMF+Vl6XhbJUDIA/fOcL/pzWRNjWSEmdH PqfhKpnfW11rHya/Njvo01So89u28E6ezsjl+u0t1tQ3odvQXkHHFnNjLNXIag9PKH3S KZpY2iyr0hMtDJ9hHoNlU9gJwvhwWzmmiCiS+cCfAm/jDS6rwmqjp39sYynpk3oiR9vb NHRg== 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 z21si12122172ejf.623.2021.06.14.13.15.18; Mon, 14 Jun 2021 13:15:41 -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 S235708AbhFNUNJ (ORCPT + 99 others); Mon, 14 Jun 2021 16:13:09 -0400 Received: from foss.arm.com ([217.140.110.172]:45930 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235499AbhFNUM4 (ORCPT ); Mon, 14 Jun 2021 16:12:56 -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 C2E9D12FC; Mon, 14 Jun 2021 13:10:52 -0700 (PDT) Received: from merodach.members.linode.com (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9ACAE3F694; Mon, 14 Jun 2021 13:10:50 -0700 (PDT) From: James Morse To: x86@kernel.org, linux-kernel@vger.kernel.org Cc: Fenghua Yu , Reinette Chatre , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Babu Moger , James Morse , shameerali.kolothum.thodi@huawei.com, Jamie Iles , D Scott Phillips OS , lcherian@marvell.com Subject: [PATCH v4 21/24] x86/resctrl: Merge the ctrl_val arrays Date: Mon, 14 Jun 2021 20:09:38 +0000 Message-Id: <20210614200941.12383-22-james.morse@arm.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210614200941.12383-1-james.morse@arm.com> References: <20210614200941.12383-1-james.morse@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Each struct rdt_hw_resource has its own ctrl_val[] array. When CDP is enabled, two resources are in use, each with its own ctrl_val[] array that holds half of the configuration used by hardware. One uses the odd slots, the other the even. rdt_cdp_peer_get() is the helper to find the alternate resource, its domain, and corresponding entry in the other ctrl_val[] array. Once the CDP resources are merged there will be one struct rdt_hw_resource and one ctrl_val[] array for each hardware resource. This will include changes to rdt_cdp_peer_get(), making it hard to bisect any issue. Merge the ctrl_val[] arrays for three CODE/DATA/NONE resources first. Doing this before merging the resources temporarily complicates allocating and freeing the ctrl_val arrays. Add a helper to allocate the ctrl_val array, that returns the value on the L2 or L3 resource if it already exists. This gets removed once the resources are merged, and there really is only one ctrl_val[] array. Reviewed-by: Jamie Iles Signed-off-by: James Morse --- Changes since v3: * Removed some parenthesis that disappear in a later patch. Changes since v2: * Shuffled commit message, Changes since v1: * Added underscores to ctrlval when its not in a function name * Removed temporary free_ctrlval_arrays() function. * Reduced churn in domain_setup_ctrlval(). --- arch/x86/kernel/cpu/resctrl/core.c | 65 ++++++++++++++++++++++++++++-- 1 file changed, 61 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c index 08603487cb7d..f0e147a209e7 100644 --- a/arch/x86/kernel/cpu/resctrl/core.c +++ b/arch/x86/kernel/cpu/resctrl/core.c @@ -509,6 +509,57 @@ void setup_default_ctrlval(struct rdt_resource *r, u32 *dc, u32 *dm) } } +static u32 *alloc_ctrlval_array(struct rdt_resource *r, struct rdt_domain *d, + bool mba_sc) +{ + /* these are for the underlying hardware, they may not match r/d */ + struct rdt_domain *underlying_domain; + struct rdt_hw_resource *hw_res; + struct rdt_hw_domain *hw_dom; + bool remapped; + + switch (r->rid) { + case RDT_RESOURCE_L3DATA: + case RDT_RESOURCE_L3CODE: + hw_res = &rdt_resources_all[RDT_RESOURCE_L3]; + remapped = true; + break; + case RDT_RESOURCE_L2DATA: + case RDT_RESOURCE_L2CODE: + hw_res = &rdt_resources_all[RDT_RESOURCE_L2]; + remapped = true; + break; + default: + hw_res = resctrl_to_arch_res(r); + remapped = false; + } + + /* + * If we changed the resource, we need to search for the underlying + * domain. Doing this for all resources would make it tricky to add the + * first resource, as domains aren't added to a resource list until + * after the ctrlval arrays have been allocated. + */ + if (remapped) + underlying_domain = rdt_find_domain(&hw_res->resctrl, d->id, + NULL); + else + underlying_domain = d; + hw_dom = resctrl_to_arch_dom(underlying_domain); + + if (mba_sc) { + if (hw_dom->mbps_val) + return hw_dom->mbps_val; + return kmalloc_array(hw_res->num_closid, + sizeof(*hw_dom->mbps_val), GFP_KERNEL); + } else { + if (hw_dom->ctrl_val) + return hw_dom->ctrl_val; + return kmalloc_array(hw_res->num_closid, + sizeof(*hw_dom->ctrl_val), GFP_KERNEL); + } +} + static int domain_setup_ctrlval(struct rdt_resource *r, struct rdt_domain *d) { struct rdt_hw_resource *hw_res = resctrl_to_arch_res(r); @@ -516,11 +567,11 @@ static int domain_setup_ctrlval(struct rdt_resource *r, struct rdt_domain *d) struct msr_param m; u32 *dc, *dm; - dc = kmalloc_array(hw_res->num_closid, sizeof(*hw_dom->ctrl_val), GFP_KERNEL); + dc = alloc_ctrlval_array(r, d, false); if (!dc) return -ENOMEM; - dm = kmalloc_array(hw_res->num_closid, sizeof(*hw_dom->mbps_val), GFP_KERNEL); + dm = alloc_ctrlval_array(r, d, true); if (!dm) { kfree(dc); return -ENOMEM; @@ -679,8 +730,14 @@ static void domain_remove_cpu(int cpu, struct rdt_resource *r) if (d->plr) d->plr->d = NULL; - kfree(hw_dom->ctrl_val); - kfree(hw_dom->mbps_val); + /* temporary: these four don't have a unique ctrlval array */ + if (r->rid != RDT_RESOURCE_L3CODE && + r->rid != RDT_RESOURCE_L3DATA && + r->rid != RDT_RESOURCE_L2CODE && + r->rid != RDT_RESOURCE_L2DATA) { + kfree(hw_dom->ctrl_val); + kfree(hw_dom->mbps_val); + } bitmap_free(d->rmid_busy_llc); kfree(d->mbm_total); kfree(d->mbm_local); -- 2.30.2