Message ID | 167778867236.1053859.12920879751317268318.stgit@bmoger-ubuntu |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp55017wrd; Thu, 2 Mar 2023 12:29:41 -0800 (PST) X-Google-Smtp-Source: AK7set95aRxgdW5Ym4PtzSLAJLXzVUWg5rp/c2JP3Bao9agfH2vbOJ+8/So0WeIzCFuO1JS/81Y6 X-Received: by 2002:a17:906:7143:b0:8af:4969:1bb4 with SMTP id z3-20020a170906714300b008af49691bb4mr11462960ejj.53.1677788980842; Thu, 02 Mar 2023 12:29:40 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1677788980; cv=pass; d=google.com; s=arc-20160816; b=cT78krX4IzfqyQt0JNKkrhguVWVNUqmN8JXkjYfJn5PdhisYe8dB9JAVZI4TZBJiQc 9ZhyqeSK/934AeuDWTL5gUatliZennV4WDRnERdBQxsAQDqXNzovVLRYHPwFeH2jRGLF nniMMoIDuYS18IayCvZ6VDrffmI1eJJnDYqDoWsn0jD0jnYmAAHOheHtsYjQwFy7CURE UxXWhDIfWm1zgp8Psm2jpicb4vxwYr1TbE0KRCeShPUEtiOjkP2EszX30SE7ilBFjcjG 1hys9+Fx2n3R07rAMccZRf6QjASsB+Dj9WCkM/acZbYOod+X1T193+zgQeZKbHUyK1U9 wy2A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:cc:to:from :subject:dkim-signature; bh=zAuZmTFRzC2XzIYM432jNnpzNS8EmX1ldEFl1zp4MPY=; b=VfrmTGDZN63kk5ngusgkhGoFu5FY8nzKHGFuwUoK5Eo38FRpE9K652sU8sLIR/0aOz Bl6pZ9x9AkblZwnm9zXm+ifChoz/psJQaV7o6msmn5KjgltxrmlB/ea6HJUyptgShn6k VDxY0sSNrVJ2AWeql4w4ucxrg5fSeoOE9udSgM/7403u7l9TsH80eEyMrCE/ZSdKPX26 Pn9Anj+IGrFE13X1pEGSfmQUqBvRDJX0PyJJUp4MyC97Ouv2uRSPRRQKDuZ+UPCgYZqk nlMpti9wqgEp31L4FWrTARPTe8EI1gLjL0chYZYWF9f+OCcno0sFi4HgkGmOLDZI4Eoo 6NCQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=pXi4Kixd; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b13-20020aa7c90d000000b004ad0caf3dc0si523774edt.480.2023.03.02.12.29.18; Thu, 02 Mar 2023 12:29:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=pXi4Kixd; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229867AbjCBUYq (ORCPT <rfc822;davidbtadokoro@gmail.com> + 99 others); Thu, 2 Mar 2023 15:24:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229862AbjCBUYj (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 2 Mar 2023 15:24:39 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2041.outbound.protection.outlook.com [40.107.236.41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F358E2F7B5; Thu, 2 Mar 2023 12:24:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lVYmm3TbMsTC6P0HAGzu41587VXuKO2Y+687Rd+j+UBIVSlv7B+dae77y8UziiLsDCsc4Ny4pg2eVd49qTdF4KV67Ok0TCaKxdBm9ANXGXiw/+naT9dIW08i0m0poU+ZU9KnQNMMytQOA3x57tg/TLh52XUu8tzBmtYA6D01f4htcU944wkdm05DcemE8AONC3Osa9UBDWP+6t5cz57BgoliTMo7lQIs8a7FIfgm04mRLeJGsfzmXu7xFNxE/yBRnNCZ+QZ0RaSHT+TNxZsrOddQQrLE2jqmWbCERB/DQ/xLd9VpOjweXt84wdpEkJ+tmhR9mWxUKaNkmSnFBfawPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zAuZmTFRzC2XzIYM432jNnpzNS8EmX1ldEFl1zp4MPY=; b=HHyEreJJRTgWrt3fe7JXrq5rRsBiS9Dyxff38HwynnVAO+uSyQ93OgSJpjspkM1523+LDqKt80pZL4cUM8UgT3sUYkCCqhJgvX7KXqXsW5ycCyUgSG8SxPjUOOFljQIkQN8GJ5delztN8YNqS4HeHCt3PxrbXKW3Tc85a0PCNd4JI6Lv8cP1oLQZkDNAhLH+XRWMRYF4fNoWkVM8KqdY1OfYRkS/9XzaOBvVkJcvzd2xR7J5hDqO/BVrQWx6+dMCXMLHkggNjofM+6XAqktxf3whxrZRnwuulBlS9qCQgtgQwM3RIYrxIELyJCXIvRZDg64xb6h9zQycSXO44Bn2rQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=quicinc.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zAuZmTFRzC2XzIYM432jNnpzNS8EmX1ldEFl1zp4MPY=; b=pXi4KixdEymdA6hZXPDnASCms1nPFe0bZ3uJqw5WRXXyJ5L47yJWhWDmsP1cozdSsuqC2qMjixpaGXf/PN7KImb3tVMH9e4RZzdsagB4n/TKtKuOCyLgjfYCee6DhiUCE0w2XBRGRJmLr/18IXMaBlzUo8Cj+XcGhPxdQM6Xyjg= Received: from DS7PR03CA0173.namprd03.prod.outlook.com (2603:10b6:5:3b2::28) by PH0PR12MB8150.namprd12.prod.outlook.com (2603:10b6:510:293::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.18; Thu, 2 Mar 2023 20:24:35 +0000 Received: from DS1PEPF0000E634.namprd02.prod.outlook.com (2603:10b6:5:3b2:cafe::9) by DS7PR03CA0173.outlook.office365.com (2603:10b6:5:3b2::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.18 via Frontend Transport; Thu, 2 Mar 2023 20:24:35 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by DS1PEPF0000E634.mail.protection.outlook.com (10.167.17.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6156.12 via Frontend Transport; Thu, 2 Mar 2023 20:24:35 +0000 Received: from [127.0.1.1] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Thu, 2 Mar 2023 14:24:33 -0600 Subject: [PATCH v3 2/7] x86/resctrl: Remove few unnecessary rftype flags From: Babu Moger <babu.moger@amd.com> To: <corbet@lwn.net>, <reinette.chatre@intel.com>, <tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de> CC: <fenghua.yu@intel.com>, <dave.hansen@linux.intel.com>, <x86@kernel.org>, <hpa@zytor.com>, <paulmck@kernel.org>, <akpm@linux-foundation.org>, <quic_neeraju@quicinc.com>, <rdunlap@infradead.org>, <damien.lemoal@opensource.wdc.com>, <songmuchun@bytedance.com>, <peterz@infradead.org>, <jpoimboe@kernel.org>, <pbonzini@redhat.com>, <babu.moger@amd.com>, <chang.seok.bae@intel.com>, <pawan.kumar.gupta@linux.intel.com>, <jmattson@google.com>, <daniel.sneddon@linux.intel.com>, <sandipan.das@amd.com>, <tony.luck@intel.com>, <james.morse@arm.com>, <linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <bagasdotme@gmail.com>, <eranian@google.com>, <christophe.leroy@csgroup.eu>, <pawan.kumar.gupta@linux.intel.com>, <jarkko@kernel.org>, <adrian.hunter@intel.com>, <quic_jiles@quicinc.com>, <peternewman@google.com>, <babu.moger@amd.com> Date: Thu, 2 Mar 2023 14:24:32 -0600 Message-ID: <167778867236.1053859.12920879751317268318.stgit@bmoger-ubuntu> In-Reply-To: <167778850105.1053859.14596357862185564029.stgit@bmoger-ubuntu> References: <167778850105.1053859.14596357862185564029.stgit@bmoger-ubuntu> User-Agent: StGit/1.1.dev103+g5369f4c MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS1PEPF0000E634:EE_|PH0PR12MB8150:EE_ X-MS-Office365-Filtering-Correlation-Id: d947cb8d-1d93-453d-5838-08db1b5c23a3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lp6ggzQH8M/I94cN0JIGvsiV/fhAhhi9216IgVoHRQ8VXF/irq8FNKVkq3pkh9rcrPkIstAv7KLROrseaJvDdLe/7sJEtxEwi0csZ4ONwxGjMZIp2c49q4Np3JEZAGngVv5BuUkFle9WPIX4dqhzbCdrEHDX7BxC5E3i/rY0HBaNo4vtI44sOh7y4wvYklY4PBoeQFY4TL/3wHMderiWWHi5davaUZ9ESNvNtw1Am1j5s2KbDecTvPa0hOSOMQFH4A+tz6qvrvO6hNHhkqAtA7h0/E/VXAlSxEWMXR5jQxYe68Tcf36iynu8DLIWelFLpAWvw8BaMwQD4PNEM28tJ8rrUYItlU/I98gq4ZcOjpbkghyLv9NaIvtS8WB4zGAsH5bqYcML2f9Y/hVkgiOibARTuQ4wdqt26eOJM0zBG2Pycqwh8xu/xwjuGy3wSdJHf/X9rj/misRHPDYkWMbkjIHeJNc4NtdMmx0wnv2ZbkTuQz3ey/x1WQzl2abxrVs9zI+BVa8KQ/h17AED2KAHHDEidPRynC4mhFaByDJAKcDBEWSuB2IiN4r7DtNbnSzwQbTJAtyfTT+bth2Mze5AGhROo4ncfUIyh7ooEplRfM6KrmjLtgEkyhOov81ugVzc6SQLWy/CuFrYuYJYl5I/qY7xmYDCBcVMDJyUvOCxA5gkM/svuN6S85cbIXz+h2UU05mFMMZKtxBP1+LeHpy29kyU9LnEpr97XyB3+FOElvZ2+GB5pxavIcnBwQekZINPKorq5yN9rp88QggVJiFBeg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(7916004)(136003)(396003)(39860400002)(376002)(346002)(451199018)(40470700004)(46966006)(36840700001)(103116003)(336012)(33716001)(82310400005)(316002)(16576012)(47076005)(478600001)(83380400001)(110136005)(54906003)(40460700003)(426003)(16526019)(186003)(36860700001)(9686003)(7416002)(86362001)(8936002)(26005)(356005)(41300700001)(2906002)(7406005)(5660300002)(70206006)(44832011)(70586007)(40480700001)(8676002)(82740400003)(4326008)(81166007)(71626013)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2023 20:24:35.1124 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d947cb8d-1d93-453d-5838-08db1b5c23a3 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS1PEPF0000E634.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB8150 X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759289258676340952?= X-GMAIL-MSGID: =?utf-8?q?1759289258676340952?= |
Series |
x86/resctrl: Miscellaneous resctrl features
|
|
Commit Message
Moger, Babu
March 2, 2023, 8:24 p.m. UTC
Remove few unnecessary rftype flags and simplify the code. This is done
to further cleanup the code eventually.
Signed-off-by: Babu Moger <babu.moger@amd.com>
---
arch/x86/kernel/cpu/resctrl/internal.h | 9 +++------
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 10 +++++++---
2 files changed, 10 insertions(+), 9 deletions(-)
Comments
Hi Babu, On 3/2/2023 12:24 PM, Babu Moger wrote: > Remove few unnecessary rftype flags and simplify the code. This is done Please drop "few" (here and in subject). > to further cleanup the code eventually. Could you please be specific? "further cleanup the code eventually" is too vague. I do not understand what is meant with the second sentence. > > Signed-off-by: Babu Moger <babu.moger@amd.com> > --- > arch/x86/kernel/cpu/resctrl/internal.h | 9 +++------ > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 10 +++++++--- > 2 files changed, 10 insertions(+), 9 deletions(-) > > diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h > index 8edecc5763d8..571145d75d29 100644 > --- a/arch/x86/kernel/cpu/resctrl/internal.h > +++ b/arch/x86/kernel/cpu/resctrl/internal.h > @@ -243,12 +243,9 @@ struct rdtgroup { > */ > #define RFTYPE_INFO BIT(0) > #define RFTYPE_BASE BIT(1) > -#define RF_CTRLSHIFT 4 > -#define RF_MONSHIFT 5 > -#define RF_TOPSHIFT 6 > -#define RFTYPE_CTRL BIT(RF_CTRLSHIFT) > -#define RFTYPE_MON BIT(RF_MONSHIFT) > -#define RFTYPE_TOP BIT(RF_TOPSHIFT) > +#define RFTYPE_CTRL BIT(4) > +#define RFTYPE_MON BIT(5) > +#define RFTYPE_TOP BIT(6) > #define RFTYPE_RES_CACHE BIT(8) > #define RFTYPE_RES_MB BIT(9) > #define RF_CTRL_INFO (RFTYPE_INFO | RFTYPE_CTRL) > diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > index 15ea5b550fe9..3c86506e54c1 100644 > --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > @@ -3163,7 +3163,7 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, > { > struct rdtgroup *prdtgrp, *rdtgrp; > struct kernfs_node *kn; > - uint files = 0; > + uint fflags = 0; Hoe does changing the variable name from "files" to "fflags" simplify the code? > int ret; > > prdtgrp = rdtgroup_kn_lock_live(parent_kn); > @@ -3215,8 +3215,12 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, > goto out_destroy; > } > > - files = RFTYPE_BASE | BIT(RF_CTRLSHIFT + rtype); > - ret = rdtgroup_add_files(kn, files); > + if (rtype == RDTCTRL_GROUP) > + fflags = RFTYPE_BASE | RFTYPE_CTRL; > + else > + fflags = RFTYPE_BASE | RFTYPE_MON; > + > + ret = rdtgroup_add_files(kn, fflags); > if (ret) { > rdt_last_cmd_puts("kernfs fill error\n"); > goto out_destroy; > > Reinette
Hi Reinette, On 3/15/23 13:33, Reinette Chatre wrote: > Hi Babu, > > On 3/2/2023 12:24 PM, Babu Moger wrote: >> Remove few unnecessary rftype flags and simplify the code. This is done > > Please drop "few" (here and in subject). Sure. > >> to further cleanup the code eventually. > > Could you please be specific? "further cleanup the code > eventually" is too vague. I do not understand what is meant > with the second sentence. I can just say "Remove unnecessary rftype flags and improve code readability." > >> >> Signed-off-by: Babu Moger <babu.moger@amd.com> >> --- >> arch/x86/kernel/cpu/resctrl/internal.h | 9 +++------ >> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 10 +++++++--- >> 2 files changed, 10 insertions(+), 9 deletions(-) >> >> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h >> index 8edecc5763d8..571145d75d29 100644 >> --- a/arch/x86/kernel/cpu/resctrl/internal.h >> +++ b/arch/x86/kernel/cpu/resctrl/internal.h >> @@ -243,12 +243,9 @@ struct rdtgroup { >> */ >> #define RFTYPE_INFO BIT(0) >> #define RFTYPE_BASE BIT(1) >> -#define RF_CTRLSHIFT 4 >> -#define RF_MONSHIFT 5 >> -#define RF_TOPSHIFT 6 >> -#define RFTYPE_CTRL BIT(RF_CTRLSHIFT) >> -#define RFTYPE_MON BIT(RF_MONSHIFT) >> -#define RFTYPE_TOP BIT(RF_TOPSHIFT) >> +#define RFTYPE_CTRL BIT(4) >> +#define RFTYPE_MON BIT(5) >> +#define RFTYPE_TOP BIT(6) >> #define RFTYPE_RES_CACHE BIT(8) >> #define RFTYPE_RES_MB BIT(9) >> #define RF_CTRL_INFO (RFTYPE_INFO | RFTYPE_CTRL) >> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> index 15ea5b550fe9..3c86506e54c1 100644 >> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> @@ -3163,7 +3163,7 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, >> { >> struct rdtgroup *prdtgrp, *rdtgrp; >> struct kernfs_node *kn; >> - uint files = 0; >> + uint fflags = 0; > > Hoe does changing the variable name from "files" to "fflags" simplify > the code? I should have said readability of the code. Its actually fflags we are passing to rdtgroup_add_files. While changing flags below, I changed the variable name to fflags. > >> int ret; >> >> prdtgrp = rdtgroup_kn_lock_live(parent_kn); >> @@ -3215,8 +3215,12 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, >> goto out_destroy; >> } >> >> - files = RFTYPE_BASE | BIT(RF_CTRLSHIFT + rtype); >> - ret = rdtgroup_add_files(kn, files); >> + if (rtype == RDTCTRL_GROUP) >> + fflags = RFTYPE_BASE | RFTYPE_CTRL; >> + else >> + fflags = RFTYPE_BASE | RFTYPE_MON; >> + >> + ret = rdtgroup_add_files(kn, fflags); >> if (ret) { >> rdt_last_cmd_puts("kernfs fill error\n"); >> goto out_destroy; >> >> > > Reinette
Hi Babu, On 3/16/2023 1:31 PM, Moger, Babu wrote: > On 3/15/23 13:33, Reinette Chatre wrote: >> On 3/2/2023 12:24 PM, Babu Moger wrote: >>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>> index 15ea5b550fe9..3c86506e54c1 100644 >>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>> @@ -3163,7 +3163,7 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, >>> { >>> struct rdtgroup *prdtgrp, *rdtgrp; >>> struct kernfs_node *kn; >>> - uint files = 0; >>> + uint fflags = 0; >> >> Hoe does changing the variable name from "files" to "fflags" simplify >> the code? > > I should have said readability of the code. Its actually fflags we are > passing to rdtgroup_add_files. While changing flags below, I changed the > variable name to fflags. You are correct in that it is the actual fflags parameter but what it reflects is which files will be created. I do not find that using "files" makes the code unreadable. Reinette
Hi Reinette, On 3/16/23 15:41, Reinette Chatre wrote: > Hi Babu, > > On 3/16/2023 1:31 PM, Moger, Babu wrote: >> On 3/15/23 13:33, Reinette Chatre wrote: >>> On 3/2/2023 12:24 PM, Babu Moger wrote: >>>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>>> index 15ea5b550fe9..3c86506e54c1 100644 >>>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>>> @@ -3163,7 +3163,7 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, >>>> { >>>> struct rdtgroup *prdtgrp, *rdtgrp; >>>> struct kernfs_node *kn; >>>> - uint files = 0; >>>> + uint fflags = 0; >>> >>> Hoe does changing the variable name from "files" to "fflags" simplify >>> the code? >> >> I should have said readability of the code. Its actually fflags we are >> passing to rdtgroup_add_files. While changing flags below, I changed the >> variable name to fflags. > > You are correct in that it is the actual fflags parameter but what it > reflects is which files will be created. I do not find that using "files" > makes the code unreadable. Everything helps. I changed it because I was already changing few things in this function. That is not the only change in this function. Here is the main change in this function. - files = RFTYPE_BASE | BIT(RF_CTRLSHIFT + rtype); - ret = rdtgroup_add_files(kn, files); + if (rtype == RDTCTRL_GROUP) + fflags = RFTYPE_BASE | RFTYPE_CTRL; + else + fflags = RFTYPE_BASE | RFTYPE_MON; + + ret = rdtgroup_add_files(kn, fflags); In my opinion this is more clearer. Also I can delete some of these un-necessary definitions below. #define RFTYPE_INFO BIT(0) #define RFTYPE_BASE BIT(1) -#define RF_CTRLSHIFT 4 -#define RF_MONSHIFT 5 -#define RF_TOPSHIFT 6 -#define RFTYPE_CTRL BIT(RF_CTRLSHIFT) -#define RFTYPE_MON BIT(RF_MONSHIFT) -#define RFTYPE_TOP BIT(RF_TOPSHIFT) +#define RFTYPE_CTRL BIT(4) +#define RFTYPE_MON BIT(5) +#define RFTYPE_TOP BIT(6) Thanks Babu
Hi Babu, On 3/16/2023 2:11 PM, Moger, Babu wrote: > Hi Reinette, > > On 3/16/23 15:41, Reinette Chatre wrote: >> Hi Babu, >> >> On 3/16/2023 1:31 PM, Moger, Babu wrote: >>> On 3/15/23 13:33, Reinette Chatre wrote: >>>> On 3/2/2023 12:24 PM, Babu Moger wrote: >>>>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>>>> index 15ea5b550fe9..3c86506e54c1 100644 >>>>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>>>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>>>> @@ -3163,7 +3163,7 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, >>>>> { >>>>> struct rdtgroup *prdtgrp, *rdtgrp; >>>>> struct kernfs_node *kn; >>>>> - uint files = 0; >>>>> + uint fflags = 0; >>>> >>>> Hoe does changing the variable name from "files" to "fflags" simplify >>>> the code? >>> >>> I should have said readability of the code. Its actually fflags we are >>> passing to rdtgroup_add_files. While changing flags below, I changed the >>> variable name to fflags. >> >> You are correct in that it is the actual fflags parameter but what it >> reflects is which files will be created. I do not find that using "files" >> makes the code unreadable. > > Everything helps. I changed it because I was already changing few things > in this function. That is not the only change in this function. Here is > the main change in this function. I did read the patch Babu. I trimmed my response to focus on what I was responding to. Our opinions differ on readability of the current variable name. This patch can focus on just removing the unnecessary rftype flags. Reinette
On 3/16/23 16:17, Reinette Chatre wrote: > Hi Babu, > > On 3/16/2023 2:11 PM, Moger, Babu wrote: >> Hi Reinette, >> >> On 3/16/23 15:41, Reinette Chatre wrote: >>> Hi Babu, >>> >>> On 3/16/2023 1:31 PM, Moger, Babu wrote: >>>> On 3/15/23 13:33, Reinette Chatre wrote: >>>>> On 3/2/2023 12:24 PM, Babu Moger wrote: >>>>>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>>>>> index 15ea5b550fe9..3c86506e54c1 100644 >>>>>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>>>>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>>>>> @@ -3163,7 +3163,7 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, >>>>>> { >>>>>> struct rdtgroup *prdtgrp, *rdtgrp; >>>>>> struct kernfs_node *kn; >>>>>> - uint files = 0; >>>>>> + uint fflags = 0; >>>>> >>>>> Hoe does changing the variable name from "files" to "fflags" simplify >>>>> the code? >>>> >>>> I should have said readability of the code. Its actually fflags we are >>>> passing to rdtgroup_add_files. While changing flags below, I changed the >>>> variable name to fflags. >>> >>> You are correct in that it is the actual fflags parameter but what it >>> reflects is which files will be created. I do not find that using "files" >>> makes the code unreadable. >> >> Everything helps. I changed it because I was already changing few things >> in this function. That is not the only change in this function. Here is >> the main change in this function. > > I did read the patch Babu. I trimmed my response to focus on what > I was responding to. Our opinions differ on readability of the current > variable name. This patch can focus on just removing the unnecessary rftype > flags. Ok. Fine with me.
diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h index 8edecc5763d8..571145d75d29 100644 --- a/arch/x86/kernel/cpu/resctrl/internal.h +++ b/arch/x86/kernel/cpu/resctrl/internal.h @@ -243,12 +243,9 @@ struct rdtgroup { */ #define RFTYPE_INFO BIT(0) #define RFTYPE_BASE BIT(1) -#define RF_CTRLSHIFT 4 -#define RF_MONSHIFT 5 -#define RF_TOPSHIFT 6 -#define RFTYPE_CTRL BIT(RF_CTRLSHIFT) -#define RFTYPE_MON BIT(RF_MONSHIFT) -#define RFTYPE_TOP BIT(RF_TOPSHIFT) +#define RFTYPE_CTRL BIT(4) +#define RFTYPE_MON BIT(5) +#define RFTYPE_TOP BIT(6) #define RFTYPE_RES_CACHE BIT(8) #define RFTYPE_RES_MB BIT(9) #define RF_CTRL_INFO (RFTYPE_INFO | RFTYPE_CTRL) diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c index 15ea5b550fe9..3c86506e54c1 100644 --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c @@ -3163,7 +3163,7 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, { struct rdtgroup *prdtgrp, *rdtgrp; struct kernfs_node *kn; - uint files = 0; + uint fflags = 0; int ret; prdtgrp = rdtgroup_kn_lock_live(parent_kn); @@ -3215,8 +3215,12 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, goto out_destroy; } - files = RFTYPE_BASE | BIT(RF_CTRLSHIFT + rtype); - ret = rdtgroup_add_files(kn, files); + if (rtype == RDTCTRL_GROUP) + fflags = RFTYPE_BASE | RFTYPE_CTRL; + else + fflags = RFTYPE_BASE | RFTYPE_MON; + + ret = rdtgroup_add_files(kn, fflags); if (ret) { rdt_last_cmd_puts("kernfs fill error\n"); goto out_destroy;