Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp117241pxf; Wed, 24 Mar 2021 00:14:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxHYv23YaAABdBGg7tgpEIZd49QlWEsQ2JuTx9cbeo4r+WFGWLrWBWKJg+rDR8b/mPsVdwx X-Received: by 2002:a05:6402:510b:: with SMTP id m11mr1877458edd.103.1616570052260; Wed, 24 Mar 2021 00:14:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616570052; cv=none; d=google.com; s=arc-20160816; b=zvTRRbL1a0SRQWc7use1bW9HumLThzhHVL4LGuBacjO38daEyUBi+nb1xCUEn6zMEO Yx/mq61H1ud4x5h/zHhZNcVpgCSCanqMPTL0VaV3CDswYGE5ocDgPVBgW2OPYy2we4ZZ F6q3ZHeYUMCwBdxLMY9uqljZh+JlxcfhYIhIzcb1C05YYA5cFVi4+BOUJO6s0H+eA6Ky bWscCX+Ihl6ulRmcoQQLZx5g6DWA4G62QvRWQ9CjiwOQfbYN4eEFPSChofAibURY7K3R CY8f3bRGw6ydjf97yL+FPRmdd+F++cAWcRMQ2UjsAyP8OuHm3CSwgg8XR2RJaHTqvYf2 XBDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=MOgWW/vmaHk16KbMwA6aGVC1+mnGo7ws7tX/r9WINkM=; b=jpzcVKJTYXYqxAto3mb2dHTYKZ8Lg3uYZr/IqIbTZpcpTNqgnWA+UFJYfAyvDuaq7C tbe9JVBfLB2zOgsKDjyiZEt1BXbwpvTnlZwJqJCvypfqCg5BcFAwnU7VyAgZo4a8YFQ6 1AFF0ikvcGCepIzWU6wJyQ6ECzyW2IIGkAixklP2eVl+HH6Lh8FCl0jZJcqcZYBKah+e jYUcnJOwrOwM+LYjw1ETH2EQ+AvVnkA6KPhA5yVqmcStXh1i6LvYPogaEXYNvVdBkD0o 6FtElA1RJGLUI2z5uA0kXNOLU+K6x7Pz7+mCfgGIptipFHNH4QnuGGIJKozLz8Tv8tkH e19A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i19si1179330ejd.152.2021.03.24.00.13.43; Wed, 24 Mar 2021 00:14:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S232253AbhCWSvn (ORCPT + 99 others); Tue, 23 Mar 2021 14:51:43 -0400 Received: from foss.arm.com ([217.140.110.172]:50624 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231344AbhCWSvb (ORCPT ); Tue, 23 Mar 2021 14:51:31 -0400 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 3636E1042; Tue, 23 Mar 2021 11:51:31 -0700 (PDT) Received: from e113632-lin (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BA2513F718; Tue, 23 Mar 2021 11:51:29 -0700 (PDT) From: Valentin Schneider To: Vincent Guittot Cc: linux-kernel , Qais Yousef , Peter Zijlstra , Ingo Molnar , Dietmar Eggemann , Morten Rasmussen , Quentin Perret , Pavan Kondeti , Rik van Riel , Lingutla Chandrasekhar Subject: Re: [PATCH v3 6/7] sched/fair: Filter out locally-unsolvable misfit imbalances In-Reply-To: References: <20210311120527.167870-1-valentin.schneider@arm.com> <20210311120527.167870-7-valentin.schneider@arm.com> <87v99srztf.mognet@arm.com> Date: Tue, 23 Mar 2021 18:51:27 +0000 Message-ID: <87pmzpya8g.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19/03/21 16:19, Vincent Guittot wrote: > On Mon, 15 Mar 2021 at 20:18, Valentin Schneider > wrote: >> As stated the current behaviour is to classify groups as group_misfit_task >> regardless of the dst_cpu's capacity. When we see a group_misfit_task >> candidate group misfit task with higher per-CPU capacity than the local >> group, we don't pick it as busiest. >> >> I initially thought not marking those as group_misfit_task was the right >> thing to do, as they could then be classified as group_fully_busy or >> group_has_spare. Consider: >> >> DIE [ ] >> MC [ ][ ] >> 0 1 2 3 >> L L B B >> >> arch_scale_capacity(L) < arch_scale_capacity(B) >> >> CPUs 0-1 are idle / lightly loaded >> CPU2 has a misfit task and a few very small tasks >> CPU3 has a few very small tasks >> >> When CPU0 is running load_balance() at DIE level, right now we'll classify >> the [2-3] group as group_misfit_task and not pick it as busiest because the >> local group has a lower CPU capacity. >> >> If we didn't do that, we could leave the misfit task alone and pull some >> small task(s) from CPU2 or CPU3, which would be a good thing to > > Are you sure? the last check in update_sd_pick_busiest() should > already filter this. So it should be enough to let it be classify > correctly > > A group should be classified as group_misfit_task when there is a task > to migrate in priority compared to some other groups. In your case, > you tag it as group_misfit_task but in order to do the opposite, i.e. > make sure to not select it. As mentioned above, this will be filter in > the last check in update_sd_pick_busiest() > This hinges on sgc->min_capacity, which might be influenced by a CPU in the candidate group being severely pressured by IRQ / thermal / RT / DL pressure. That said, you have a point in that this check and the one in find_busiest_queue() catches most scenarios I can think of. Let me ponder about this some more, and if throw it at the test infrastructure monster if I go down that route.