Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp706542rwr; Thu, 27 Apr 2023 07:12:18 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5ts+KRiNVgMFX/+VnCB1/LLWNrg+aThzcuwEHXRNvNCro8+XzCOZs/w8OTSL76eLJNcGAE X-Received: by 2002:a05:6a21:3392:b0:f6:d60d:dbae with SMTP id yy18-20020a056a21339200b000f6d60ddbaemr2348862pzb.6.1682604738336; Thu, 27 Apr 2023 07:12:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682604738; cv=none; d=google.com; s=arc-20160816; b=aN3sv+sbzm3gGNVSq9h71PZ5lhaPGnBKljlQXBWGwMv+xivo4UnBX1GG5MpM7qWrhu 2ChfADsQQoyXHtJo2L4e4jwkI0voPpuIcJ5DG+yUQeCKx/XaiYKXB30B5x2P2qZ6bmg0 QwTckc150Kq+U3BdecLyECtCGjj+GIPJ55cDqOGuOvfBsvi6IS4WGQrD1cQjafa3m79v C6x4lFa+RB5o44EGqcr+26VAqKVM1yV19DvcZMIwHMdBLmSeR2QTwwcjWHEX5bTwge6b p0mGXuPyX2mal1Zd653nrcnkfqhqLRgrHczhagmYFaN7bmrrRVuQa8TwC2+4ABCP8uwl yW6g== 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=1LYlXXMNj2H3PPP8y06MD1MoEWesX0XIIo8ELMv7RfM=; b=C4D+QfurIWedmffnYs6LincDpiSj5viRjbs9v7fYFJxJbSID+/4vZ6L+e3k2RQ7zlo p5HWN4j+68rLCII+2ZIXiR1yWirwZI9o8JsipTJOdkFYVSjDALVqPi2pNMbgZhEPvcAa 4lMdbKdqvEu4K1pRxHX8lOEmQUYPLR24p1YKpBMH6C6ndPRxD9H+1pkNmvsWABeiSQaI RhV6kgOgxB5FehqLUXmhITmADZ9yAn0hS0vHKRC7UMbpe5vEjl5GWd30+XHPqWCRZhEg GWla7nCtOhWHF/9XsV54/3WOjZninqq5Bnv396xwd9dJlRejiN3hNr8a/n99OtPeXzVA yX2w== ARC-Authentication-Results: i=1; mx.google.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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w4-20020aa79544000000b0063d23b80e00si18634557pfq.392.2023.04.27.07.12.01; Thu, 27 Apr 2023 07:12:18 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243797AbjD0OKT (ORCPT + 99 others); Thu, 27 Apr 2023 10:10:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243795AbjD0OKN (ORCPT ); Thu, 27 Apr 2023 10:10:13 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6597D46AE for ; Thu, 27 Apr 2023 07:10:12 -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 19F452F4; Thu, 27 Apr 2023 07:10:56 -0700 (PDT) Received: from [10.1.196.177] (eglon.cambridge.arm.com [10.1.196.177]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1B0463F64C; Thu, 27 Apr 2023 07:09:50 -0700 (PDT) Message-ID: <87a8ee28-903a-b561-5736-3543ff1550ae@arm.com> Date: Thu, 27 Apr 2023 15:09:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH v3 06/19] x86/resctrl: Allow the allocator to check if a CLOSID can allocate clean RMID Content-Language: en-GB To: Reinette Chatre , x86@kernel.org, linux-kernel@vger.kernel.org Cc: Fenghua Yu , 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 References: <20230320172620.18254-1-james.morse@arm.com> <20230320172620.18254-7-james.morse@arm.com> <37c2371c-11e6-a2ef-059a-1a0ba08c2f67@intel.com> From: James Morse In-Reply-To: <37c2371c-11e6-a2ef-059a-1a0ba08c2f67@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham 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: X-Mailing-List: linux-kernel@vger.kernel.org Hi Reinette, On 01/04/2023 00:21, Reinette Chatre wrote: > On 3/20/2023 10:26 AM, James Morse wrote: >> +/** >> + * resctrl_closid_is_dirty - Determine if all RMID associated with this CLOSID >> + * are available. >> + * @closid: The CLOSID that is being queried. >> + * >> + * MPAM's equivalent of RMID are per-CLOSID, meaning a freshly allocated CLOSID >> + * may not be able to allocate clean RMID. To avoid this the allocator will >> + * only return clean CLOSID. This is enough for now as it allows MPAM systems >> + * to use resctrl. This suffers from the problem that there may be no CLOSID >> + * where all the RMID are clean, causing the CLOSID allocation to fail. >> + * This can be improved (once MPAM support is upstream) to return the cleanest >> + * CLOSID where PMG=0 is clean. This would allow the CLOSID allocation to > Why does PMG=0 have to be the clean ID? True, there ends up being a second search anyway. > I am wondering about the use cases here. When a new CLOSID needs to be allocated, > would it not be useful to instead have a utility that returns the "cleanest" CLOSID? It would, but this is a trade off between churn and features, I'm trying to do the minimum to get feature parity for supporting MPAM by keeping any additional code that x86 doesn't use small and simple. Improvements that only affect MPAM can be kicked down the road. But as we're discussing it... > Instead of picking an available CLOSID and then always have to check if it is > "dirty or not", why not have a utility that picks the CLOSID with the most > available PMGs? I think an extra array to keep track of this is simplest as it avoids a complex walk of the rmid_ptrs[] array looking for the global minimum across a number of entries. I think it would be two additional patches. I'll include this in the next version. Thanks, James