Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B139CC61DA4 for ; Mon, 6 Mar 2023 18:08:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230351AbjCFSIv (ORCPT ); Mon, 6 Mar 2023 13:08:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230412AbjCFSIc (ORCPT ); Mon, 6 Mar 2023 13:08:32 -0500 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A8FBD4EE7 for ; Mon, 6 Mar 2023 10:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678126078; x=1709662078; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=lqKN6PeUXaaQFo9qkkt8utGGixrotBUL+bwOQcjrpIk=; b=kDIinGcqtySa7bF7MGJSbcGjwdhmPxW5LJCO/frpawyInZh4tiQFQ0sm m2sQ6AcwBZ+I2GvAzEh4sJQ5Z7/YAH+zkZKP4B3Uedqt8cihEdovzFJIR XWm6w1ZPu0ZJMdo1lCTea45OOwMkJIKN9lKp22d5ni1+8iepcoVDzYNWE TcIkI0YId0nDtNdN2yI7d8XqhUJ8PBNodPssxcEovqHIsOr4A9Ujh8em+ tVgwRKlmU3pODNUBd0/Kkzjxpp3wheLRlifbVvjFIxQd2lJ4oRd4PQ/wy y46srq/p9VKkkDUbBYdPxo7BICrx/fN2bEdNveZXdikbA9kLQdaqPICiM w==; X-IronPort-AV: E=McAfee;i="6500,9779,10641"; a="398215126" X-IronPort-AV: E=Sophos;i="5.98,238,1673942400"; d="scan'208";a="398215126" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Mar 2023 10:07:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10641"; a="745163433" X-IronPort-AV: E=Sophos;i="5.98,238,1673942400"; d="scan'208";a="745163433" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by fmsmga004.fm.intel.com with ESMTP; 06 Mar 2023 10:07:21 -0800 Date: Mon, 6 Mar 2023 10:17:23 -0800 From: Ricardo Neri To: Ionela Voinescu Cc: "Peter Zijlstra (Intel)" , Juri Lelli , Vincent Guittot , Ricardo Neri , "Ravi V. Shankar" , Ben Segall , Daniel Bristot de Oliveira , Dietmar Eggemann , Len Brown , Mel Gorman , "Rafael J. Wysocki" , Srinivas Pandruvada , Steven Rostedt , Tim Chen , Valentin Schneider , x86@kernel.org, linux-kernel@vger.kernel.org, "Tim C . Chen" Subject: Re: [PATCH v3 08/10] sched/topology: Remove SHARED_CHILD from ASYM_PACKING Message-ID: <20230306181723.GA3153@ranerica-svr.sc.intel.com> References: <20230207045838.11243-1-ricardo.neri-calderon@linux.intel.com> <20230207045838.11243-9-ricardo.neri-calderon@linux.intel.com> <20230305190811.GA4352@ranerica-svr.sc.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 06, 2023 at 01:10:37PM +0000, Ionela Voinescu wrote: > Hey, > > On Sunday 05 Mar 2023 at 11:08:11 (-0800), Ricardo Neri wrote: > > On Fri, Mar 03, 2023 at 11:29:52AM +0000, Ionela Voinescu wrote: > > > Hi Ricardo, > > > > Hi Ionela! > > > > > > > > On Monday 06 Feb 2023 at 20:58:36 (-0800), Ricardo Neri wrote: > > > > Only x86 and Power7 use ASYM_PACKING. They use it differently. > > > > > > > > Power7 has cores of equal priority, but the SMT siblings of a core have > > > > different priorities. Parent scheduling domains do not need (nor have) the > > > > ASYM_PACKING flag. SHARED_CHILD is not needed. Using SHARED_PARENT would > > > > cause the topology debug code to complain. > > > > > > > > X86 has cores of different priority, but all the SMT siblings of the core > > > > have equal priority. It needs ASYM_PACKING at the MC level, but not at the > > > > SMT level (it also needs it at upper levels if they have scheduling groups > > > > of different priority). Removing ASYM_PACKING from the SMT domain causes > > > > the topology debug code to complain. > > > > > > > > Remove SHARED_CHILD for now. We still need a topology check that satisfies > > > > both architectures. > > > > > > > > Cc: Ben Segall > > > > Cc: Daniel Bristot de Oliveira > > > > Cc: Dietmar Eggemann > > > > Cc: Len Brown > > > > Cc: Mel Gorman > > > > Cc: Rafael J. Wysocki > > > > Cc: Srinivas Pandruvada > > > > Cc: Steven Rostedt > > > > Cc: Tim C. Chen > > > > Cc: Valentin Schneider > > > > Cc: x86@kernel.org > > > > Cc: linux-kernel@vger.kernel.org > > > > Suggested-by: Valentin Schneider > > > > Signed-off-by: Ricardo Neri > > > > --- > > > > Changes since v2: > > > > * Introduced this patch. > > > > > > > > Changes since v1: > > > > * N/A > > > > --- > > > > include/linux/sched/sd_flags.h | 5 +---- > > > > 1 file changed, 1 insertion(+), 4 deletions(-) > > > > > > > > diff --git a/include/linux/sched/sd_flags.h b/include/linux/sched/sd_flags.h > > > > index 57bde66d95f7..800238854ba5 100644 > > > > --- a/include/linux/sched/sd_flags.h > > > > +++ b/include/linux/sched/sd_flags.h > > > > @@ -132,12 +132,9 @@ SD_FLAG(SD_SERIALIZE, SDF_SHARED_PARENT | SDF_NEEDS_GROUPS) > > > > /* > > > > * Place busy tasks earlier in the domain > > > > * > > > > - * SHARED_CHILD: Usually set on the SMT level. Technically could be set further > > > > - * up, but currently assumed to be set from the base domain > > > > - * upwards (see update_top_cache_domain()). > > > > * NEEDS_GROUPS: Load balancing flag. > > > > */ > > > > -SD_FLAG(SD_ASYM_PACKING, SDF_SHARED_CHILD | SDF_NEEDS_GROUPS) > > > > +SD_FLAG(SD_ASYM_PACKING, SDF_NEEDS_GROUPS) > > > > > > While this silences the warning one would have gotten when removing > > > SD_ASYM_PACKING from SMT level, it will still result in sd_asym_packing > > > being NULL for these systems, which breaks nohz balance. That is because > > > highest_flag_domain() still stops searching at the first level without > > > the flag set, in this case SMT, even if levels above have the flag set. > > > > You are absolutely right! This how this whole discussion started. It > > slipped my mind. > > > > > > > > Maybe highest_flag_domain() should be changed to take into account the > > > metadata flags? > > > > What about the patch below? Search will stop if the flag has > > SDF_SHARED_CHILD as it does today. Otherwise it will search all the > > domains. > > > > --- a/kernel/sched/sched.h > > +++ b/kernel/sched/sched.h > > @@ -1773,6 +1773,12 @@ queue_balance_callback(struct rq *rq, > > for (__sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd); \ > > __sd; __sd = __sd->parent) > > > > +#define SD_FLAG(name, mflags) (name * !!((mflags) & SDF_SHARED_CHILD)) | > > +static const unsigned int SD_SHARED_CHILD_MASK = > > +#include > > +0; > > +#undef SD_FLAG > > + > > /** > > * highest_flag_domain - Return highest sched_domain containing flag. > > * @cpu: The CPU whose highest level of sched domain is to > > @@ -1781,15 +1787,19 @@ queue_balance_callback(struct rq *rq, > > * for the given CPU. > > * > > * Returns the highest sched_domain of a CPU which contains the given flag. > > - */ > > +*/ > ^^^ > likely an unintended change Yes! I will remove it in the patch I post. > > static inline struct sched_domain *highest_flag_domain(int cpu, int flag) > > { > > struct sched_domain *sd, *hsd = NULL; > > > > for_each_domain(cpu, sd) { > > - if (!(sd->flags & flag)) > > + if (sd->flags & flag) { > > + hsd = sd; > > + continue; > > + } > > + > > There might be room for a comment here: > /* > * If the flag is not set and is known to be shared with lower > * domains, stop the search, as it won't be found further up. > */ Sure, I can and a comment to this effect. > > + if (flag & SD_SHARED_CHILD_MASK) > > break; > > - hsd = sd; > > } > > > > return hsd; > > It looks nice and sane to me - I've not compiled or tested it :). Thank you very much for your feedback! BR, Ricardo