Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp5919825rdb; Thu, 14 Dec 2023 03:39:53 -0800 (PST) X-Google-Smtp-Source: AGHT+IFN4jYcBgTLEhawO6Q91BWT3+H2PRVWIzdhzIOls9kNp+pUbEsyUGh3qaHrAUpGQeKKkwxP X-Received: by 2002:a17:90a:8d86:b0:286:b91c:7774 with SMTP id d6-20020a17090a8d8600b00286b91c7774mr4615618pjo.47.1702553993430; Thu, 14 Dec 2023 03:39:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702553993; cv=none; d=google.com; s=arc-20160816; b=bH20hi2RM0t4zeBq+AaJLLB05fGkSZ6bbCFGRc/9Yg6niUxBY8VjevLTAX2FPDspY9 Vrf7n5ac+lNzQr2W+H6yT/5amuWnAmgosFKIEdbPe0y73DcWwmHKNjiKnZLqnzlx1Qv+ Ac8tlC70htzQ4PBdhdjxe1wWna8J9qgdc4eJ77ZRHG/m//AZrkw4bwyDLIellYu1lcwY oQdpjKOBjK8G+XAJJ6PoqGhZJtR3GkZ+EcS04UBQNwIGCGSB6jmChq/90TSxCbcT3z1z OqKBu6Yarg/FUUOPYuKjND4v7ZQgS+jShuXPxB/kJjRcy6P5MkDL4WPv9z8zz02sq8mN I4pA== 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=cl2sn1/obSXswNy3EigfmeXj3Qvs8XtccHa1SKabewU=; fh=V3EXrfhtPXQ8VZs+995Yo8T+zOpBnshrD4ANVkhZrjM=; b=mzswfdycDHtrc909itz7VsmKNBQQZDtEwlDQYkuR8D6dKLmWLUcKvhvCUamyNuogN7 CdjSNzCBk51ISjPGjNqKfocVIlRSeun7u3dvvOvwGxRhOEpmlp5tMjYwSF0ifAipQ6rU r/AR0XGMBEuWIZaAeKE14UwnI5yfrMRV6+JjaV6POfjnHLU9VWvHEzD1bnvjSeVoiFC6 /8jPID5GdIviXoS+UBDPMAVPWdVhxg5eOfXUCuBYkQ0DHDeD/ij0YjuypQJfevuB9fBq SbkXq1A5+DYlcbAdl50DyTL279f+tU3FQcv1T3gnbltvqXtuA63sfUvBDMUFC2Zq2fzT +SAA== 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:7 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. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id ei21-20020a17090ae55500b0028ad758dad9si3310585pjb.39.2023.12.14.03.39.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Dec 2023 03:39:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 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 1AD41802766F; Thu, 14 Dec 2023 03:39:52 -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 S1444074AbjLNLjl (ORCPT + 99 others); Thu, 14 Dec 2023 06:39:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1444128AbjLNLjZ (ORCPT ); Thu, 14 Dec 2023 06:39:25 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0AC891FD3 for ; Thu, 14 Dec 2023 03:39:03 -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 1F42BC15; Thu, 14 Dec 2023 03:39:49 -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 E76F73F738; Thu, 14 Dec 2023 03:39:00 -0800 (PST) Message-ID: Date: Thu, 14 Dec 2023 11:38:59 +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 21/24] x86/resctrl: Allow overflow/limbo handlers to be scheduled on any-but cpu 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-22-james.morse@arm.com> <9084cb79-22bd-4cb3-b48d-f0d8d71aa47c@intel.com> From: James Morse In-Reply-To: <9084cb79-22bd-4cb3-b48d-f0d8d71aa47c@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:39:52 -0800 (PST) Hi Reinette, On 09/11/2023 17:48, Reinette Chatre wrote: > On 10/25/2023 11:03 AM, James Morse wrote: >> When a CPU is taken offline resctrl may need to move the overflow or >> limbo handlers to run on a different CPU. >> >> Once the offline callbacks have been split, cqm_setup_limbo_handler() >> will be called while the CPU that is going offline is still present >> in the cpu_mask. >> >> Pass the CPU to exclude to cqm_setup_limbo_handler() and >> mbm_setup_overflow_handler(). These functions can use a variant of >> cpumask_any_but() when selecting the CPU. -1 is used to indicate no CPUs >> need excluding. >> >> A subsequent patch moves these calls to be before CPUs have been removed, >> so this exclude_cpus behaviour is temporary. > > Note "A subsequent patch". Please do go over your entire series. I may not > have noticed all. Yup, I've searched the git-log and removed those paragraphs from the x86 patches in my tree. >> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h >> index c4c1e1909058..f5fff2f0d866 100644 >> --- a/arch/x86/kernel/cpu/resctrl/internal.h >> +++ b/arch/x86/kernel/cpu/resctrl/internal.h >> @@ -61,19 +61,36 @@ >> * cpumask_any_housekeeping() - Choose any CPU in @mask, preferring those that >> * aren't marked nohz_full >> * @mask: The mask to pick a CPU from. >> + * @exclude_cpu:The CPU to avoid picking. >> * >> - * Returns a CPU in @mask. If there are housekeeping CPUs that don't use >> - * nohz_full, these are preferred. >> + * Returns a CPU from @mask, but not @exclude_cpu. If there are housekeeping >> + * CPUs that don't use nohz_full, these are preferred. Pass >> + * RESCTRL_PICK_ANY_CPU to avoid excluding any CPUs. >> + * >> + * When a CPU is excluded, returns >= nr_cpu_ids if no CPUs are available. >> */ >> -static inline unsigned int cpumask_any_housekeeping(const struct cpumask *mask) >> +static inline unsigned int >> +cpumask_any_housekeeping(const struct cpumask *mask, int exclude_cpu) >> { >> unsigned int cpu, hk_cpu; >> >> - cpu = cpumask_any(mask); >> - if (!tick_nohz_full_cpu(cpu)) >> + if (exclude_cpu == RESCTRL_PICK_ANY_CPU) >> + cpu = cpumask_any(mask); >> + else >> + cpu = cpumask_any_but(mask, exclude_cpu); >> + >> + if (!IS_ENABLED(CONFIG_NO_HZ_FULL)) >> + return cpu; > > It is not clear to me how cpumask_any_but() failure is handled. > > cpumask_any_but() returns ">= nr_cpu_ids if no cpus set" ... It wasn't a satisfiable request, there are no CPUs for this domain other than the one that was excluded. cpumask_any_but() also describes its errors as "returns >= nr_cpu_ids if no CPUs are available". The places this can happen in resctrl are: cqm_setup_limbo_handler(), where it causes the schedule_delayed_work_on() call to be skipped. mbm_setup_overflow_handler(), which does similar. These two cases are triggered from resctrl_offline_cpu() when the last CPU in a domain is going offline, and the domain is about to be free()d. This is how the limbo/overflow 'threads' stop. >> + >> + /* If the CPU picked isn't marked nohz_full, we're done */ > > Please don't impersonate code. > >> + if (cpu <= nr_cpu_ids && !tick_nohz_full_cpu(cpu)) >> return cpu; > > Is this intended to be "cpu < nr_cpu_ids"? Yes, fixed - thanks! > But that would have > code continue ... so maybe it needs explicit error check of > cpumask_any_but() failure with an earlier exit? I'm not sure what the problem you refer to here is. If 'cpu' is valid, and not marked nohz_full, nothing more needs doing. If 'cpu' is invalid or a CPU marked nohz_full, then a second attempt is made to find a housekeeping CPU into 'hk_cpu'. If the second attempt is valid, it's used in preference. An error is returned if the request couldn't be satisfied, i.e. an empty mask was passed, or the only CPU set in the mask was excluded. There is a second attempt in this case for a housekeeping CPU - but that will fail too. As above, this only happens when CPUs are going offline, and this error is handled by the caller. Thanks, James