Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1446130pxf; Fri, 12 Mar 2021 09:39:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJwyYgFjPLEkdIo/ShTTUCiRScqj3ml5bBoHEQrhg9CNkZvJNYPKceSXuPvBXHYSn+Q31ind X-Received: by 2002:a02:c6ae:: with SMTP id o14mr357597jan.33.1615570746296; Fri, 12 Mar 2021 09:39:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615570746; cv=none; d=google.com; s=arc-20160816; b=eMszPCLncujicwyIgXBGFfx2Vr5+GYMjmwJ0L5rLdvdU3N8SnwN+7YHBI7KursSX2S ps1MALIt2p5iU0cnkq3cIqCkVBucckL1c465gAJ7vHlofdpdxi5iD2nZhW++zxWNEY7T larcyY5kkYpfapBeU9rMkcR7jbAbg62dnoWLo9KjO0oDgqonxNL2ejTd73ncg+TJT1D6 mlxPjUV80RlGpIlkex7lm9Ln/gtlydmUXkzkPDf7h1KFK1Fp+xJAA0b+SOBdqvXgPhwE 2M1W55jR9ohDoO8tKqIYz/u25wNpxw21e6idIVVzr6hIvhy+KEjJ7aSBVtlAvw9LJ73t Uw5A== 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=Z7IzQdAEHiIwfxrgqXpKkvHCID6TRygQepE3WRA82CU=; b=1H5Qi2wuwno2NFnwMeP4GuzB397EQortviQYkDJboE86tTCbZf8aBgGM3S1HMLTvMl bIm3Qx9uqI0DsfH6BCcnQy4WKT1Wf4Y/6l9ME06jwt9VnTWOBe1EWkpzPVkgomT0Qw4M peMeAu/Tp51H8mK/JfHrvPV7JqO8xP8HYVmIaM4B7elkkLtvTkEwKYpsFgpvcDP8+0T+ 8qL3sjzBf74fJGaCyH3ShGfZbWUGUa14gX9IJ0NW6hLKVYSPj4PXON15GefZb8thnWj6 kHLHDuV9zHaVRn8X8vsHJtjWP5p5s/kJLaU6Fpvx3x2Q6yPgSiMzkEUe7HQSXtVpesZm 9XTQ== 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 c18si5609574ilo.43.2021.03.12.09.38.52; Fri, 12 Mar 2021 09:39:06 -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 S232686AbhCLRh7 (ORCPT + 99 others); Fri, 12 Mar 2021 12:37:59 -0500 Received: from foss.arm.com ([217.140.110.172]:57984 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232888AbhCLRhv (ORCPT ); Fri, 12 Mar 2021 12:37:51 -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 7AB3B1FB; Fri, 12 Mar 2021 09:37:51 -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 EF87A3F7D7; Fri, 12 Mar 2021 09:37:49 -0800 (PST) From: James Morse Subject: Re: [PATCH 08/24] x86/resctrl: Walk the resctrl schema list instead of an arch list 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-9-james.morse@arm.com> Message-ID: Date: Fri, 12 Mar 2021 17:37:48 +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: 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 22:52, Reinette Chatre wrote: > On 10/30/2020 9:11 AM, James Morse wrote: >> Now that resctrl has its own list of resources it is using, walk that >> list instead of the architectures list. This means resctrl has somewhere >> to keep schema properties with the resource that is using them. >> >> Most users of for_each_alloc_enabled_rdt_resource() are per-schema, >> and also want a schema property, like the conf_type. Switch these to >> walk the schema list. Schema were only created for alloc_enabled >> resources so these two lists are currently equivalent. >> > > From what I understand based on this description the patch will essentially change > instances of for_each_alloc_enabled_rdt_resource() to walking the schema list .... >> diff --git a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c >> b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c >> index 8ac104c634fe..d3f9d142f58a 100644 >> --- a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c >> +++ b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c >> @@ -57,9 +57,10 @@ static bool bw_validate(char *buf, unsigned long *data, struct >> rdt_resource *r) >>       return true; >>   } >>   -int parse_bw(struct rdt_parse_data *data, struct rdt_resource *r, >> +int parse_bw(struct rdt_parse_data *data, struct resctrl_schema *s, >>            struct rdt_domain *d) >>   { >> +    struct rdt_resource *r = s->res; >>       unsigned long bw_val; >>         if (d->have_new_ctrl) { > > ... this change and also the ones to parse_cbm() and rdtgroup_cbm_overlaps() are not clear > to me because it seems they replace the rdt_resource parameter with resctrl_schema, but > all in turn use that to access rdt_resource again. That seems unnecessary? I previously restructured the series to do the schema stuff first, as I thought it would make it easier to follow. It looks like this patch has picked up other stuff - I 'll split this up so those changes get their own commit message. By the end of the series, the rdt_resource isn't unique, the same 'L3' is provided to L3CODE and L3DATA. The things that make these different are stored in the schema. In both these cases the configuration is read/written, where that should go depends on the type of the schema, which lives in the schema struct. Thanks, James