From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D46F626E14F for ; Fri, 28 Feb 2025 13:54:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740750879; cv=none; b=ZBr1T6Ba3aiYQF1IEckZNmhpsDsz9fAcN11dmd/BTy6fw+wSaENmaj+/AAEdbD5JYkPkePT3kIZKya0yYQdqgiX0127GJW0TgnODZSRGv1fAQViGK4yVgmXrJeaMc/9CE8nzFwAI1rhFfga8hcizimzulW8NT3EMtZGf7+OAcyI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740750879; c=relaxed/simple; bh=iGWw15qAOshxKoxfswTya2Ck3Irxn54l0NaI7MI4s9U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=soXAecJwPpRaMwoPat7Ri3h/pG82HynaU33gF+d5dSsuHvuU8Oj2EjqvHfgk/2rRwwiaYoB+G54Pz/HSwbtuodEw8IalonXzrtcHgpygD18fjXQXPCZq2+cQSUk9fZJ6GuL+bbF0z7QgwnHLKuToN8KKehB0Zyt5lq0ZhJ8CD0A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 4DACD1688; Fri, 28 Feb 2025 05:54:51 -0800 (PST) Received: from bogus (e133711.arm.com [10.1.196.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DF7283F6A8; Fri, 28 Feb 2025 05:54:31 -0800 (PST) Date: Fri, 28 Feb 2025 13:54:29 +0000 From: Sudeep Holla To: Yicong Yang Cc: , , , Sudeep Holla , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v11 2/4] arch_topology: Support SMT control for OF based system Message-ID: References: <20250218141018.18082-1-yangyicong@huawei.com> <20250218141018.18082-3-yangyicong@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250218141018.18082-3-yangyicong@huawei.com> On Tue, Feb 18, 2025 at 10:10:16PM +0800, Yicong Yang wrote: > From: Yicong Yang > > On building the topology from the devicetree, we've already > gotten the SMT thread number of each core. Update the largest > SMT thread number and enable the SMT control by the end of > topology parsing. > > The core's SMT control provides two interface to the users [1]: > 1) enable/disable SMT by writing on/off > 2) enable/disable SMT by writing thread number 1/max_thread_number > > If a system have more than one SMT thread number the 2) may > not handle it well, since there're multiple thread numbers in the > system and 2) only accept 1/max_thread_number. So issue a warning > to notify the users if such system detected. > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-devices-system-cpu#n542 > > Signed-off-by: Yicong Yang > --- > drivers/base/arch_topology.c | 27 +++++++++++++++++++++++++++ > 1 file changed, 27 insertions(+) > > diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c > index 3ebe77566788..23f425a9d77a 100644 > --- a/drivers/base/arch_topology.c > +++ b/drivers/base/arch_topology.c > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -506,6 +507,10 @@ core_initcall(free_raw_capacity); > #endif > > #if defined(CONFIG_ARM64) || defined(CONFIG_RISCV) > + > +/* Maximum SMT thread number detected used to enable the SMT control */ > +static unsigned int max_smt_thread_num; > + > /* > * This function returns the logic cpu number of the node. > * There are basically three kinds of return values: > @@ -565,6 +570,16 @@ static int __init parse_core(struct device_node *core, int package_id, > i++; > } while (1); > > + /* > + * If max_smt_thread_num has been initialized and doesn't match > + * the thread number of this entry, then the system has > + * heterogeneous SMT topology. > + */ > + if (max_smt_thread_num && max_smt_thread_num != i) > + pr_warn_once("Heterogeneous SMT topology is partly supported by SMT control\n"); > + May be we need to make it more conditional as we may have to support systems with few cores that are single threaded ? I think Dietmar's comment is about that. > + max_smt_thread_num = max_t(unsigned int, max_smt_thread_num, i); > + > cpu = get_cpu_for_node(core); > if (cpu >= 0) { > if (!leaf) { > @@ -677,6 +692,18 @@ static int __init parse_socket(struct device_node *socket) > if (!has_socket) > ret = parse_cluster(socket, 0, -1, 0); > > + /* > + * Notify the CPU framework of the SMT support. Initialize the > + * max_smt_thread_num to 1 if no SMT support detected or failed > + * to parse the topology. A thread number of 1 can be handled by > + * the framework so we don't need to check max_smt_thread_num to > + * see we support SMT or not. > + */ > + if (!max_smt_thread_num || ret) > + max_smt_thread_num = 1; > + For the failed parsing of topology, reset_cpu_topology() gets called. I suggest resetting max_smt_thread_num to 1 belongs there. And if you start with max_smt_thread_num, we don't need to update it to 1 explicitly here. So I would like to get rid of above check completely. -- Regards, Sudeep