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 5AE02C05027 for ; Wed, 8 Feb 2023 07:56:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231152AbjBHH4v (ORCPT ); Wed, 8 Feb 2023 02:56:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43356 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230134AbjBHH4q (ORCPT ); Wed, 8 Feb 2023 02:56:46 -0500 Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D9A02B60C for ; Tue, 7 Feb 2023 23:56:44 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id n2so12534541pfo.3 for ; Tue, 07 Feb 2023 23:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=crkO54afLAgsJgdC5GpCChR+pEjtVxO1bJbJ06Q0a9A=; b=MUyFTQeKZHQfSOUJdukzCiukH4Ua+tMjRllnEcvbRibBH1Ydn9cPXuiLv0BiErmxKV 9ttRxFXha1O6tUQVhGfi5kgng19LedssfvarpgXzP84fBV1THPuUa7hx8LF8pHwmj1+E OK8fkw/ncfFqqLr7CzmX0uTWCK5ON9JV6WcFiCWAXWUyN6m5R+2iHg+oARbqvdPhno6d kU4fd/YAgh8syPB2+VW6inGhiQaG662c3eGklkLxcxNKU6PIFSifY+OEbeBjmqBQKFtU BfAAuew90eC4uSi9FRjzv8Drjp28CCqk7YYMUPnWTpcumTFdOs7CgiwiAr5wFkmJrLNl WIcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=crkO54afLAgsJgdC5GpCChR+pEjtVxO1bJbJ06Q0a9A=; b=JWgMj63vAeUJs2SNXRtd3HJ31N055pyxaw2Jz3FuC5zdS69myblFfA8YP2MoOhEbzX IEvsBEvOv3k8+QBFSR0QdougonFV5vdGUBTBiU52BkzHV6hxdRlGiUIBajhtZa/i75om 6K/l9rAW7w+X/nNVeTfqVkN0pbpMHAHQ/w8E1jvZrecf3/DwxhSttTFAQ03e+JcuDc1G V1CrSexkT9/YIB/RdLFm1V7FFJDVo7KXyX2itEthGTdCxBeLjvdpGvoEmYTrK2vvqGVj hGDUUWRKsnuVXl42xiG0DKb4NnEYPkAwiov1oWlvXQnIi/ndnGBh3C4Jl/IepzaIAB0n 8AGw== X-Gm-Message-State: AO0yUKVs6TMd/J9s9nRUdNGdbUwa80zt6ioOD9zJ3Ml+9TSkAPFolchh ipy+1gKlJoDU/+Oz8TRYJWuARm26VqRQVOoL0rw3sg== X-Google-Smtp-Source: AK7set8ATv7Jv51fWR/roo/jzNf7bMqH4w+qKf1lOVZ3pghRlN7fsOG+zMrvSvGgTOz2insHe8tHvHVMVJUlp9ff9hY= X-Received: by 2002:a62:31c6:0:b0:591:4b17:22b5 with SMTP id x189-20020a6231c6000000b005914b1722b5mr645704pfx.14.1675843003468; Tue, 07 Feb 2023 23:56:43 -0800 (PST) MIME-Version: 1.0 References: <20230207045838.11243-1-ricardo.neri-calderon@linux.intel.com> <20230207045838.11243-5-ricardo.neri-calderon@linux.intel.com> In-Reply-To: <20230207045838.11243-5-ricardo.neri-calderon@linux.intel.com> From: Vincent Guittot Date: Wed, 8 Feb 2023 08:56:32 +0100 Message-ID: Subject: Re: [PATCH v3 04/10] sched/fair: Let low-priority cores help high-priority busy SMT cores To: Ricardo Neri Cc: "Peter Zijlstra (Intel)" , Juri Lelli , 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 , Ionela Voinescu , x86@kernel.org, linux-kernel@vger.kernel.org, "Tim C . Chen" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 7 Feb 2023 at 05:50, Ricardo Neri wrote: > > Using asym_packing priorities within an SMT core is straightforward. Just > follow the priorities that hardware indicates. > > When balancing load from an SMT core, also consider the idle of its > siblings. Priorities do not reflect that an SMT core divides its throughput > among all its busy siblings. They only makes sense when exactly one sibling > is busy. > > Indicate that active balance is needed if the destination CPU has lower > priority than the source CPU but the latter has busy SMT siblings. > > Make find_busiest_queue() not skip higher-priority SMT cores with more than > busy sibling. > > 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 > --- > kernel/sched/fair.c | 31 ++++++++++++++++++++++++++----- > 1 file changed, 26 insertions(+), 5 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 80c86462c6f6..c9d0ddfd11f2 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -10436,11 +10436,20 @@ static struct rq *find_busiest_queue(struct lb_env *env, > nr_running == 1) > continue; > > - /* Make sure we only pull tasks from a CPU of lower priority */ > + /* > + * Make sure we only pull tasks from a CPU of lower priority > + * when balancing between SMT siblings. > + * > + * If balancing between cores, let lower priority CPUs help > + * SMT cores with more than one busy sibling. > + */ > if ((env->sd->flags & SD_ASYM_PACKING) && > sched_asym_prefer(i, env->dst_cpu) && > - nr_running == 1) > - continue; > + nr_running == 1) { > + if (env->sd->flags & SD_SHARE_CPUCAPACITY || > + (!(env->sd->flags & SD_SHARE_CPUCAPACITY) && is_core_idle(i))) This 2nd if could be merged with the upper one --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -10518,11 +10518,10 @@ static struct rq *find_busiest_queue(struct lb_env *env, */ if ((env->sd->flags & SD_ASYM_PACKING) && sched_asym_prefer(i, env->dst_cpu) && - nr_running == 1) { - if (env->sd->flags & SD_SHARE_CPUCAPACITY || - (!(env->sd->flags & SD_SHARE_CPUCAPACITY) && is_core_idle(i))) + (nr_running == 1) && + (env->sd->flags & SD_SHARE_CPUCAPACITY || + (!(env->sd->flags & SD_SHARE_CPUCAPACITY) && is_core_idle(i)))) continue; - } switch (env->migration_type) { case migrate_load: --- AFAICT, you can even remove one env->sd->flags & SD_SHARE_CPUCAPACITY test with the below but this make the condition far less obvious diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index a6021af9de11..7dfa30c45327 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -10518,11 +10518,10 @@ static struct rq *find_busiest_queue(struct lb_env *env, */ if ((env->sd->flags & SD_ASYM_PACKING) && sched_asym_prefer(i, env->dst_cpu) && - nr_running == 1) { - if (env->sd->flags & SD_SHARE_CPUCAPACITY || - (!(env->sd->flags & SD_SHARE_CPUCAPACITY) && is_core_idle(i))) + (nr_running == 1) && + !(!(env->sd->flags & SD_SHARE_CPUCAPACITY) && + !is_core_idle(i))) continue; - } > + continue; > + } > > switch (env->migration_type) { > case migrate_load: > @@ -10530,8 +10539,20 @@ asym_active_balance(struct lb_env *env) > * lower priority CPUs in order to pack all tasks in the > * highest priority CPUs. > */ > - return env->idle != CPU_NOT_IDLE && (env->sd->flags & SD_ASYM_PACKING) && > - sched_asym_prefer(env->dst_cpu, env->src_cpu); > + if (env->idle != CPU_NOT_IDLE && (env->sd->flags & SD_ASYM_PACKING)) { > + /* Always obey priorities between SMT siblings. */ > + if (env->sd->flags & SD_SHARE_CPUCAPACITY) > + return sched_asym_prefer(env->dst_cpu, env->src_cpu); > + > + /* > + * A lower priority CPU can help an SMT core with more than one > + * busy sibling. > + */ > + return sched_asym_prefer(env->dst_cpu, env->src_cpu) || > + !is_core_idle(env->src_cpu); > + } > + > + return false; > } > > static inline bool > -- > 2.25.1 >