From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B349CD37B4 for ; Sun, 17 Sep 2023 21:01:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239723AbjIQVB2 convert rfc822-to-8bit (ORCPT ); Sun, 17 Sep 2023 17:01:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239717AbjIQVBM (ORCPT ); Sun, 17 Sep 2023 17:01:12 -0400 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.86.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AAFE6B6 for ; Sun, 17 Sep 2023 14:01:03 -0700 (PDT) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-173-5VIfJed7MXGh7MjJ3HyGRg-1; Sun, 17 Sep 2023 22:00:50 +0100 X-MC-Unique: 5VIfJed7MXGh7MjJ3HyGRg-1 Received: from AcuMS.Aculab.com (10.202.163.4) by AcuMS.aculab.com (10.202.163.4) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Sun, 17 Sep 2023 22:00:40 +0100 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Sun, 17 Sep 2023 22:00:40 +0100 From: David Laight To: 'James Morse' , "x86@kernel.org" , "linux-kernel@vger.kernel.org" CC: Fenghua Yu , Reinette Chatre , Thomas Gleixner , "Ingo Molnar" , Borislav Petkov , H Peter Anvin , Babu Moger , "shameerali.kolothum.thodi@huawei.com" , D Scott Phillips OS , "carl@os.amperecomputing.com" , "lcherian@marvell.com" , "bobo.shaobowang@huawei.com" , "tan.shaopeng@fujitsu.com" , "xingxin.hx@openanolis.org" , "baolin.wang@linux.alibaba.com" , Jamie Iles , Xin Hao , "peternewman@google.com" , "dfustini@baylibre.com" , "amitsinght@marvell.com" Subject: RE: [PATCH v6 09/24] x86/resctrl: Use set_bit()/clear_bit() instead of open coding Thread-Topic: [PATCH v6 09/24] x86/resctrl: Use set_bit()/clear_bit() instead of open coding Thread-Index: AQHZ5zAaDgmrK1w/n0WuE13QIAvATLAfhSSQ Date: Sun, 17 Sep 2023 21:00:40 +0000 Message-ID: <6f7b411db77846b2a305b93d0cf0ee7b@AcuMS.aculab.com> References: <20230914172138.11977-1-james.morse@arm.com> <20230914172138.11977-10-james.morse@arm.com> In-Reply-To: <20230914172138.11977-10-james.morse@arm.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: James Morse > Sent: 14 September 2023 18:21 > > The resctrl CLOSID allocator uses a single 32bit word to track which > CLOSID are free. The setting and clearing of bits is open coded. > > A subsequent patch adds resctrl_closid_is_free(), which adds more open > coded bitmaps operations. These will eventually need changing to use > the bitops helpers so that a CLOSID bitmap of the correct size can be > allocated dynamically. > > Convert the existing open coded bit manipulations of closid_free_map > to use set_bit() and friends. > > int closids_supported(void) > @@ -126,7 +126,7 @@ static void closid_init(void) > closid_free_map = BIT_MASK(rdt_min_closid) - 1; > > /* CLOSID 0 is always reserved for the default group */ > - closid_free_map &= ~1; > + clear_bit(0, &closid_free_map); Don't the clear_bit() etc functions use locked accesses? These are always measurably more expensive than the C operators. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)