Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp618556imi; Thu, 21 Jul 2022 07:44:11 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vA1nJGrdz/8nd2A7XPV4zbWEjpxywpjhgZr66dPB+lNSR0JtTkcQ90p/8j9v+TWVQ+lucD X-Received: by 2002:a17:902:ea0b:b0:16c:3f3a:cb32 with SMTP id s11-20020a170902ea0b00b0016c3f3acb32mr43237845plg.150.1658414651300; Thu, 21 Jul 2022 07:44:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658414651; cv=none; d=google.com; s=arc-20160816; b=UV7mEooJtdZ1Rd4g9RN0fucqy41cDkTTwokXVZvbskvfRGsdHXsnAueuVK8KASp+qp 3lkzwqs/86gcE+sYAM0l1b7mk0GTJEj4KSa4vvNhpgJeFYc4sV2cphphCS3zB1+56ouB gtu2RgJnDS1dKUpzfIJ/3DRESIoahE5SrS+9X+WMLKNOsgz4f7FSWebsmfnp/0hi3ZDR nQu4dIFPDhn7DQ0lhAP5N0r2u4cSfBXOReRWjXcFmToni5YPFUlSmMUQzubXNyKOjXOU NQ5F39nV0aCliX3hDCWO/Cl8hqzzEPgZp4Ua0zP9ErWUwsjXvtJ0lcG89z1z2wqr72lK ZeRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=SuZFhdEHpUfQcmZpZLsq8g35JYT4YfgQCjlSKC7fSHI=; b=mUoRp/pVG+HIHxGAe+br6vSVvdNl8Vi1+X/jJrKM3Wh2MXNyLXENoN4rQzb7j1t4QZ PTF/li42dl6lGrm35zJKx3vHkO5eujleVGodXhmhvAclSjR8ZX+WAuGMlBES5sE3J4Gl JAoKgT+qGDlFzCIJRrukYAH+9WlKH5PbXOZVNysdfbQDfxHigqiOmN9dvPtbflGPc1Tu UuWZ4ZiyWh4yzRMOZpwrHkcsPuJl69v1NuVVafEd5LiwqBlrKrox4Zg4i4E8OJRoE0f6 3e3lyinZjw8GpX0UtsaWadZPMiDpZBnovRywp/iuzv5uhG43rZ12RGAavixbi+A0m5Sm DRMw== 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 c5-20020a170902b68500b0016c29e43c72si2384440pls.140.2022.07.21.07.43.56; Thu, 21 Jul 2022 07:44:11 -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 S231978AbiGUO37 (ORCPT + 99 others); Thu, 21 Jul 2022 10:29:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232198AbiGUO3y (ORCPT ); Thu, 21 Jul 2022 10:29:54 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id AB77381B2D for ; Thu, 21 Jul 2022 07:29:52 -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 E9F9C1042; Thu, 21 Jul 2022 07:29:52 -0700 (PDT) Received: from wubuntu (unknown [10.57.86.173]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 233D33F73D; Thu, 21 Jul 2022 07:29:51 -0700 (PDT) Date: Thu, 21 Jul 2022 15:29:49 +0100 From: Qais Yousef To: Vincent Guittot Cc: Ingo Molnar , "Peter Zijlstra (Intel)" , Dietmar Eggemann , linux-kernel@vger.kernel.org, Xuewen Yan , Wei Wang , Jonathan JMChen , Hank Subject: Re: [PATCH 2/7] sched/uclamp: Make task_fits_capacity() use util_fits_cpu() Message-ID: <20220721142949.fqmabrjwylkuoltw@wubuntu> References: <20220629194632.1117723-1-qais.yousef@arm.com> <20220629194632.1117723-3-qais.yousef@arm.com> <20220712104843.frbtkgkiftaovcon@wubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220712104843.frbtkgkiftaovcon@wubuntu> X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_NONE 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 On 07/12/22 11:48, Qais Yousef wrote: > On 07/11/22 15:09, Vincent Guittot wrote: > > On Wed, 29 Jun 2022 at 21:48, Qais Yousef wrote: > > [...] > > > > @@ -8502,15 +8504,16 @@ static void update_cpu_capacity(struct sched_domain *sd, int cpu) > > > trace_sched_cpu_capacity_tp(cpu_rq(cpu)); > > > > > > sdg->sgc->capacity = capacity; > > > - sdg->sgc->min_capacity = capacity; > > > - sdg->sgc->max_capacity = capacity; > > > + sdg->sgc->min_capacity_cpu = cpu; > > > + sdg->sgc->max_capacity_cpu = cpu; > > > > you make these fields useless. There is only one cpu per sched_group > > at this level so you don't need to save the twice cpu number of the > > nly cpu of this group > > Ah, so we can use group->asym_prefer_cpu then? > > I think I got confused and thought we could cover multiple capacity levels > there. > > > > } > > > > > > void update_group_capacity(struct sched_domain *sd, int cpu) > > > { > > > - struct sched_domain *child = sd->child; > > > struct sched_group *group, *sdg = sd->groups; > > > - unsigned long capacity, min_capacity, max_capacity; > > > + struct sched_domain *child = sd->child; > > > + int min_capacity_cpu, max_capacity_cpu; > > > + unsigned long capacity; > > > unsigned long interval; > > > > > > interval = msecs_to_jiffies(sd->balance_interval); > > > @@ -8523,8 +8526,7 @@ void update_group_capacity(struct sched_domain *sd, int cpu) > > > } > > > > > > capacity = 0; > > > - min_capacity = ULONG_MAX; > > > - max_capacity = 0; > > > + min_capacity_cpu = max_capacity_cpu = cpu; > > > > > > if (child->flags & SD_OVERLAP) { > > > /* > > > @@ -8536,29 +8538,44 @@ void update_group_capacity(struct sched_domain *sd, int cpu) > > > unsigned long cpu_cap = capacity_of(cpu); > > > > > > capacity += cpu_cap; > > > - min_capacity = min(cpu_cap, min_capacity); > > > - max_capacity = max(cpu_cap, max_capacity); > > > + if (cpu_cap < capacity_of(min_capacity_cpu)) > > > + min_capacity_cpu = cpu; > > > + > > > + if (cpu_cap > capacity_of(max_capacity_cpu)) > > > + max_capacity_cpu = cpu; > > > } > > > } else { > > > /* > > > * !SD_OVERLAP domains can assume that child groups > > > * span the current group. > > > */ > > > + unsigned long min_capacity = ULONG_MAX; > > > + unsigned long max_capacity = 0; > > > > > > group = child->groups; > > > do { > > > struct sched_group_capacity *sgc = group->sgc; > > > + unsigned long cpu_cap_min = capacity_of(sgc->min_capacity_cpu); > > > + unsigned long cpu_cap_max = capacity_of(sgc->max_capacity_cpu); > > > > By replacing sgc->min_capacity with sgc->min_capacity_cpu, the > > min_capacity is no more stable and can become > max_capacity > > Right. > > > > > > > > > capacity += sgc->capacity; > > > - min_capacity = min(sgc->min_capacity, min_capacity); > > > - max_capacity = max(sgc->max_capacity, max_capacity); > > > + if (cpu_cap_min < min_capacity) { > > > + min_capacity = cpu_cap_min; > > > + min_capacity_cpu = sgc->min_capacity_cpu; > > > + } > > > + > > > + if (cpu_cap_max > max_capacity) { > > > + max_capacity = cpu_cap_max; > > > + max_capacity_cpu = sgc->max_capacity_cpu; > > > + } > > > + > > > group = group->next; > > > } while (group != child->groups); > > > } > > > > > > sdg->sgc->capacity = capacity; > > > - sdg->sgc->min_capacity = min_capacity; > > > - sdg->sgc->max_capacity = max_capacity; > > > + sdg->sgc->min_capacity_cpu = min_capacity_cpu; > > > + sdg->sgc->max_capacity_cpu = max_capacity_cpu; > > > } > > > > > > /* > > > @@ -8902,7 +8919,7 @@ static bool update_sd_pick_busiest(struct lb_env *env, > > > * internally or be covered by avg_load imbalance (eventually). > > > */ > > > if (sgs->group_type == group_misfit_task && > > > - (!capacity_greater(capacity_of(env->dst_cpu), sg->sgc->max_capacity) || > > > + (!capacity_greater(env->dst_cpu, sg->sgc->max_capacity_cpu) || > > > sds->local_stat.group_type != group_has_spare)) > > > return false; > > > > > > @@ -8986,7 +9003,7 @@ static bool update_sd_pick_busiest(struct lb_env *env, > > > */ > > > if ((env->sd->flags & SD_ASYM_CPUCAPACITY) && > > > (sgs->group_type <= group_fully_busy) && > > > - (capacity_greater(sg->sgc->min_capacity, capacity_of(env->dst_cpu)))) > > > + (capacity_greater(sg->sgc->min_capacity_cpu, env->dst_cpu))) > > > return false; > > > > > > return true; > > > @@ -9108,7 +9125,7 @@ static inline void update_sg_wakeup_stats(struct sched_domain *sd, > > > > > > /* Check if task fits in the group */ > > > if (sd->flags & SD_ASYM_CPUCAPACITY && > > > - !task_fits_capacity(p, group->sgc->max_capacity)) { > > > + !task_fits_cpu(p, group->sgc->max_capacity_cpu)) { > > > > All the changes and added complexity above for this line. Can't you > > find another way ? > > You're right, I might have got carried away trying to keep the logic the same. > > Can we use group->asym_prefer_cpu or pick a cpu from group->sgc->cpumask > instead? > > I'll dig more into it anyway and try to come up with simpler alternative. Actually we can't. I can keep the current {max,min}_capacity field and just add the new {max,min}_capacity_cpu and use them where needed. Should address your concerns this way? That was actually the first version of the code, but then it seemed redundant to keep both {max,min}_capacity and {max,min}_capacity_cpu. OR I can add a new function to search for max spare capacity cpu in the group. Preference? Thanks! -- Qais Yousef