Received: by 2002:a05:7412:2a8c:b0:e2:908c:2ebd with SMTP id u12csp4041628rdh; Fri, 29 Sep 2023 09:20:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFF6u3KDu4uxOGGUQeNsGsOqt2fV7bAtLLSB3IR5IUTdN49Cef2vxIPG37rMZrtoPMUciU8 X-Received: by 2002:a17:90a:6acd:b0:274:9a85:2596 with SMTP id b13-20020a17090a6acd00b002749a852596mr4817715pjm.32.1696004428987; Fri, 29 Sep 2023 09:20:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696004428; cv=none; d=google.com; s=arc-20160816; b=XXBciEkgv/Llo2+MyZHguEZRpmwHV9EQf1BvxPOLpiOl0J12UXya8XdJ7M31lVq6r0 nP/RnepC0EgGbXemYws19i1rEpHkPixDHQOYUUsUnNywoQ3SMVGBdAGfudUnxvP8skQE Ue87yvaAvK40+5lndEW0METnPrCukpYbjavzbuLheuVTVRUfEg1beTfYDYq+Ms4Pd3zL e5bCT8gF+VmqTGGZb62+7hS9mmF/0bAKatNC9t01awztcQba3EwSDUIFFcBCjhL4rJmO Bchrs0Xp1h9uxIiscUGlGEGSrDSuWYHuPhSb8vMoUxKxFiA3y1VeGnHeqMCUKn187k/0 k11w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=tV3g9j0+wsI9B3N7RW9rrpCK9AdYpW8920pYx5rm+No=; fh=KFAQDErfOZO4ES1/2Cxo9ps9uDhq3csGhUNdlt/01g0=; b=LILqDzIU/zt/6Tn5tzBYvRIxitsyM9uwTHbZylcj6iq3PSosNpgvMJIOL4TpHy/VPB 1GcXGc1NczkuAY2A61micL7puzpXNnqWOkOEJLSU9y8X/Hq1CTDvQt/HytNONneDuVAa Cik7W6LYmKnJq3BMyLMO1WJI6F8XKAcJ0oJxSp+XCTyMb2C6r7BPtM+KZeHqX6VpGcVr 6LyYmwdFAmHcLcNkrZ6xzaJldSaSU5q6g07Wxfm2sncNJbW1ylsoytF/EWw7bumriTvJ XvDGbqOvZOF1sBs+zJMGkgm8n73tw6HvVpWImSCKJLWOpW7K/j3StkWkKMtFoCTmM/fX Yqbg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 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 morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id ng11-20020a17090b1a8b00b002774b340c1fsi2018525pjb.69.2023.09.29.09.20.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Sep 2023 09:20:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 3C6EC802092D; Fri, 29 Sep 2023 09:14:03 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232883AbjI2QN6 (ORCPT + 99 others); Fri, 29 Sep 2023 12:13:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229826AbjI2QN5 (ORCPT ); Fri, 29 Sep 2023 12:13:57 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 29774199 for ; Fri, 29 Sep 2023 09:13:55 -0700 (PDT) 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 343771FB; Fri, 29 Sep 2023 09:14:33 -0700 (PDT) Received: from [10.1.197.60] (eglon.cambridge.arm.com [10.1.197.60]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4489B3F59C; Fri, 29 Sep 2023 09:13:52 -0700 (PDT) Message-ID: Date: Fri, 29 Sep 2023 17:13:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v6 09/24] x86/resctrl: Use set_bit()/clear_bit() instead of open coding Content-Language: en-GB To: David Laight , "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" References: <20230914172138.11977-1-james.morse@arm.com> <20230914172138.11977-10-james.morse@arm.com> <6f7b411db77846b2a305b93d0cf0ee7b@AcuMS.aculab.com> From: James Morse In-Reply-To: <6f7b411db77846b2a305b93d0cf0ee7b@AcuMS.aculab.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Fri, 29 Sep 2023 09:14:03 -0700 (PDT) Hi David, On 17/09/2023 22:00, David Laight wrote: > 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? Yes. In this case there is no need for it to be atomic, just to use the bitmap API so this can be made bigger in the future. It's currently protected by the rdtgroup_mutex (I'll add some lockdep annotations to document that). > These are always measurably more expensive than the C operators. I'll switch this to use the double-underscore version which are non-atomic, double-underscore is usually a warning not to use this function! I doubt the performance matters as this is only ever called from a mkdir() syscall when the configuration is changed, which we anticipate only really happens once at boot. Thanks, James