Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1425482pxf; Fri, 12 Mar 2021 09:11:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJxD0N5wkBlad2KGTDr4qn1edVQ5NTaCYFXer6++sbNZnJpcENgkD8cxPgPXRjHWNlR+Wnut X-Received: by 2002:a17:906:1386:: with SMTP id f6mr9552506ejc.45.1615569114147; Fri, 12 Mar 2021 09:11:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615569114; cv=none; d=google.com; s=arc-20160816; b=BS09D8cSDIvbLeNgeI9fJoZUKj8r5hXDVTYuS/SLQSgWRlujwQv+eqLq7g5TO+bqNu mLcjrqGBQgUx6Wvlo2oQSERkiXW8L2lZnzWObXskvgEnwF6ef44IwzZVsZBLwdQ627c1 DFuBHA24AU7UfXgsXZa9FMCY5hAPM+JDuo/nNIw08x8LN6YyJTuTKMhLunvKOdBvH6ae KmLmFgqXkZKdtszRu0/ZoG8HYm8fNZxvd9XnUQaVLaP7HC0zeJ1Tcd3lEhxwnmeMWxDo Yaz/ZDlZJJxZb2K80hheDMBBbnqDg/2tkPdqBrE/E8BtxK6tb5dosVoFKWfnQRoNWnOQ 7P9w== 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:references:cc :to:subject:from; bh=s9BMTbrw7VZ97EIBqiNih2WLoPh37HKw+5ibTOHlqMA=; b=OQfoQDg3syYC55tZ6iAE0+RnqKOy8FNrgy215LKWbi1ndRjQ6WzZDL5YkGu81UHHpO fWFkcneG51W2PafuEcishBFeP0JcYdQqFJ4r36ebCRdV/0BfJeK3mvhobsr4ZQOeKBef kyXR845SSgXtUd0joRDexDGkdse4un2tLUv7WECFss7qA5lqDP1xLkPCy8aM3A6zhysn I+ZAFro3gXqgH0TGxY6PBNw4BMJjrAEQ/eglSh+2UxfX3lAB3W1rwrRvzOvSc6nSEUJC XjadRDX2yeVaOf+pZRGbWJN3YNX78NqFcVcb4qw9blY77c/+c9ZsDGs28hM2SmSdKXqF Pypg== 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 u5si4578301ejf.438.2021.03.12.09.11.30; Fri, 12 Mar 2021 09:11:54 -0800 (PST) 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 S232043AbhCLRKe (ORCPT + 99 others); Fri, 12 Mar 2021 12:10:34 -0500 Received: from foss.arm.com ([217.140.110.172]:57526 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231519AbhCLRKJ (ORCPT ); Fri, 12 Mar 2021 12:10:09 -0500 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 9EE9D1FB; Fri, 12 Mar 2021 09:10:08 -0800 (PST) Received: from [192.168.0.14] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1DC243F7D7; Fri, 12 Mar 2021 09:10:06 -0800 (PST) From: James Morse Subject: Re: [PATCH 01/24] x86/resctrl: Split struct rdt_resource To: Reinette Chatre , x86@kernel.org, linux-kernel@vger.kernel.org Cc: Fenghua Yu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , shameerali.kolothum.thodi@huawei.com, Jamie Iles , D Scott Phillips OS References: <20201030161120.227225-1-james.morse@arm.com> <20201030161120.227225-2-james.morse@arm.com> <8a49d89f-a68b-bd10-60c1-33f59258ea9f@intel.com> Message-ID: <2e159387-384b-794a-0d9e-1405e5333276@arm.com> Date: Fri, 12 Mar 2021 17:10:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <8a49d89f-a68b-bd10-60c1-33f59258ea9f@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Reinette, On 17/11/2020 19:20, Reinette Chatre wrote: > On 10/30/2020 9:10 AM, James Morse wrote: >> Splitting rdt_domain up in a similar way happens in the next patch. >> No change in behaviour, this patch just moves types around. > > Please remove the "this patch" term. >> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c >> index e5f4ee8f4c3b..470661f2eb68 100644 >> --- a/arch/x86/kernel/cpu/resctrl/core.c >> +++ b/arch/x86/kernel/cpu/resctrl/core.c >> @@ -912,9 +938,14 @@ static __init bool get_rdt_resources(void) >>     static __init void rdt_init_res_defs_intel(void) >>   { >> +    struct rdt_hw_resource *hw_res; >>       struct rdt_resource *r; >> +    int i; >> + >> +    for (i = 0; i < RDT_NUM_RESOURCES; i++) { >> +        hw_res = &rdt_resources_all[i]; >> +        r = &rdt_resources_all[i].resctrl; >>   -    for_each_rdt_resource(r) { >>           if (r->rid == RDT_RESOURCE_L3 || >>               r->rid == RDT_RESOURCE_L3DATA || >>               r->rid == RDT_RESOURCE_L3CODE || > > Could using for_each_rdt_resource() remain with the additional assignment of hw_res? > Similar to the later usage of for_each_alloc_enabled_rdt_resource()? Sure. I didn't do it here because of the back-to-back container_of(), even though the array is defined in the same file. But the compiler will remove all of that. >> diff --git a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c >> b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c >> index c877642e8a14..ab6e584c9d2d 100644 >> --- a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c >> +++ b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c >> @@ -284,10 +284,12 @@ int update_domains(struct rdt_resource *r, int closid) >>   static int rdtgroup_parse_resource(char *resname, char *tok, >>                      struct rdtgroup *rdtgrp) >>   { >> +    struct rdt_hw_resource *hw_res; >>       struct rdt_resource *r; >>         for_each_alloc_enabled_rdt_resource(r) { >> -        if (!strcmp(resname, r->name) && rdtgrp->closid < r->num_closid) >> +        hw_res = resctrl_to_arch_res(r); >> +        if (!strcmp(resname, r->name) && rdtgrp->closid < hw_res->num_closid) >>               return parse_line(tok, r, rdtgrp); >>       } > This is the usage of for_each_alloc_enabled_rdt_resource() I refer to earlier. (if it helps, the difference in treatment is because this one is to do with the filesystem interface, the others were clearly arch code) Thanks, James