Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp5918875rdb; Thu, 14 Dec 2023 03:37:57 -0800 (PST) X-Google-Smtp-Source: AGHT+IHGiNeFuhZ/KkRW+CT28+SbRE+kwHz+UqOWbDx/ZX6TeUAUKCr7AUvoB9Ra55UdQ1RS4cqz X-Received: by 2002:a05:6a00:460f:b0:6ce:4866:f388 with SMTP id ko15-20020a056a00460f00b006ce4866f388mr6076958pfb.24.1702553877633; Thu, 14 Dec 2023 03:37:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702553877; cv=none; d=google.com; s=arc-20160816; b=IMHpzHS7nONqEncWj90X/SZzWOOUx1QfBPB/ccLc0TC6oUKa4M5XOCHEMABChn2qiQ JLkZ7Ni1Gzg/bnZIWoKJy8ZcCylySQdOKlGvQEnL6Q+8ALqq0ub9BDNBOWoVlCc7M4Aq xYtztypRZT7DI5FHTEikrFwQc8hiGgHS89NdXLkZ0bk/YxDpYsfKJkz8CIf8MVgerIt9 xzP0zVuQ8l+JoQ0ob+pqxq/YUlMoLbS32WDJ1pDUH5bNzQrqll33g8nYEdAd+J5UN+i1 LK3wUpyhPuWjqu8AnBdA/gA2p4C1yrfY87IQxdoaTSvH7t6j6AjeP+ND6X1S44DeNQkX taVg== 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=JvkJN/EMNAYUUrPPSY7AbESSCoh+NTK4FCsPYAflKMo=; fh=V3EXrfhtPXQ8VZs+995Yo8T+zOpBnshrD4ANVkhZrjM=; b=n8Nly/AqcqZqd8X6ZVL3hjSFCte+nI/ZhD01jvl5FzwftGY4u+9eacNFGBAHZVFSWl D09TstroXeADUFwFKPNEjgYXo5aMyuBtmoQaCHRr/Mbm5dYHXIzNC0VtREUYDWbU/MMz eREYjdND1o1Ddg/MNXKGW4i/BTCuVxCrUPI/mTdFOqGx7IsWqj1WHxjQvt40Lf7Rh3VB 7m9mlNxZnFOU8tGlvgKFG9TvVjzsf76q7Awaxq9NSKG4cuJo0ifbf1gzzH0jsE0FIJFk Lge8CEiJtngSjErpdPvxlkg5dL+mcwRIgnHIljyOr3m4hSGk5qeg7xMU/44r0lrQMllh L5Cw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 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 snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id a38-20020a056a001d2600b006d0c0196858si3372983pfx.288.2023.12.14.03.37.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Dec 2023 03:37:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 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 snail.vger.email (Postfix) with ESMTP id 9D2A8802886F; Thu, 14 Dec 2023 03:37:56 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1443999AbjLNLhm (ORCPT + 99 others); Thu, 14 Dec 2023 06:37:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1444087AbjLNLhc (ORCPT ); Thu, 14 Dec 2023 06:37:32 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CC91012D for ; Thu, 14 Dec 2023 03:37:38 -0800 (PST) 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 22F54C15; Thu, 14 Dec 2023 03:38:24 -0800 (PST) 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 240C63F738; Thu, 14 Dec 2023 03:37:35 -0800 (PST) Message-ID: Date: Thu, 14 Dec 2023 11:37:34 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v7 14/24] x86/resctrl: Allow resctrl_arch_rmid_read() to sleep 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, baolin.wang@linux.alibaba.com, Jamie Iles , Xin Hao , peternewman@google.com, dfustini@baylibre.com, amitsinght@marvell.com References: <20231025180345.28061-1-james.morse@arm.com> <20231025180345.28061-15-james.morse@arm.com> <73bcd9f2-7c2d-4e9e-bcd8-ce3de2f9a5a4@intel.com> From: James Morse In-Reply-To: <73bcd9f2-7c2d-4e9e-bcd8-ce3de2f9a5a4@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.2 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 14 Dec 2023 03:37:56 -0800 (PST) Hi Reinette, On 09/11/2023 17:47, Reinette Chatre wrote: > On 10/25/2023 11:03 AM, James Morse wrote: >> MPAM's cache occupancy counters can take a little while to settle once >> the monitor has been configured. The maximum settling time is described >> to the driver via a firmware table. The value could be large enough >> that it makes sense to sleep. To avoid exposing this to resctrl, it >> should be hidden behind MPAM's resctrl_arch_rmid_read(). >> >> resctrl_arch_rmid_read() may be called via IPI meaning it is unable >> to sleep. In this case resctrl_arch_rmid_read() should return an error >> if it needs to sleep. This will only affect MPAM platforms where >> the cache occupancy counter isn't available immediately, nohz_full is >> in use, and there are no housekeeping CPUs in the necessary domain. >> >> There are three callers of resctrl_arch_rmid_read(): >> __mon_event_count() and __check_limbo() are both called from a >> non-migrateable context. mon_event_read() invokes __mon_event_count() >> using smp_call_on_cpu(), which adds work to the target CPUs workqueue. >> rdtgroup_mutex() is held, meaning this cannot race with the resctrl >> cpuhp callback. __check_limbo() is invoked via schedule_delayed_work_on() >> also adds work to a per-cpu workqueue. >> >> The remaining call is add_rmid_to_limbo() which is called in response >> to a user-space syscall that frees an RMID. This opportunistically >> reads the LLC occupancy counter on the current domain to see if the >> RMID is over the dirty threshold. This has to disable preemption to >> avoid reading the wrong domain's value. Disabling pre-emption here >> prevents resctrl_arch_rmid_read() from sleeping. >> >> add_rmid_to_limbo() walks each domain, but only reads the counter >> on one domain. If the system has more than one domain, the RMID will >> always be added to the limbo list. If the RMIDs usage was not over the >> threshold, it will be removed from the list when __check_limbo() runs. >> Make this the default behaviour. Free RMIDs are always added to the >> limbo list for each domain. >> >> The user visible effect of this is that a clean RMID is not available >> for re-allocation immediately after 'rmdir()' completes, this behaviour >> was never portable as it never happened on a machine with multiple >> domains. >> >> Removing this path allows resctrl_arch_rmid_read() to sleep if its called >> with interrupts unmasked. Document this is the expected behaviour, and >> add a might_sleep() annotation to catch changes that won't work on arm64. [...] >> Changes since v3: >> * Removed error handling for smp_call_function_any(), this can't race >> with the cpuhp callbacks as both hold rdtgroup_mutex. >> * Switched to the alternative of removing the counter read, this simplifies >> things dramatically. >> >> Changes since v4: >> * Messed with capitalisation. >> * Removed some dead code now that entry->busy will never be zero in >> add_rmid_to_limbo(). >> * Rephrased the comment above resctrl_arch_rmid_read_context_check(). >> >> Changes since v5: >> * Really rephrased the comment above resctrl_arch_rmid_read_context_check(). >> >> No changes since v6 > > If I trusted this I would not have taken the time to review this patch. I'm not sure what you want me to do from this comment ... but this 'no changes' annotation doesn't work for either of us, so I'll remove them. > Reviewed-by: Reinette Chatre Thanks, James