Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp291016pxf; Thu, 11 Mar 2021 04:07:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJzEzifQRG2gpwb/K3+FWg87xjgGisY46kNbeSea2am/R+M+VfuwviHUlV7xAYLHlVLi3sUk X-Received: by 2002:a05:6402:35cd:: with SMTP id z13mr8229806edc.21.1615464437844; Thu, 11 Mar 2021 04:07:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615464437; cv=none; d=google.com; s=arc-20160816; b=B2aC1i+xu5Da+y12gnd5hE/ZzUqEXuLlS45uRd1iAMZcYdWsyblKuUg9RIs4xp1vxm I2ae6ZpDGsn4dc6wNWI0/oVYd9vBhAh0bWMUZb+60I1pNVIWa9gjlmzZfwVZHGhRLick o6FJaL1n4mOBvFNBO6g/x1zZA/S39bZMtvTem6l3qEAXVtUwD8Kvhanb/IlAwYaonQdp Dp5f1Oq4DDiYwYokasNZ8CbIbAYqtuh1fsfij5BJ0xBE/Z6mEE7rTN6Qoos+A6OqlsUs Ak27rC0IXD0PjVZsZoHspF8DCuAOSJGd3H2bc4hK54W5cWvk+XGoe39JkvPorTJJEFBJ 0LvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=fS8j/GZuX54zviELZzO0yDQAOB1A/duRoIl9KDxqLhs=; b=KoQGc4UBuhHpfvKMHfzSkYVBFzCV5WNe3VkeLPxcaw1fYJkDTHmemWmEJ/Kd2hXHyI qj72yTznN0Ta5yd4U6Jd9aCtHH/vruesVvHd1nsT6+S9mx9ZKyeVvPNY5+kzHINmeME6 nYbaV/mz73p/AompUpNRag/i86pLIMwHDoFrUnK8gzIZYK/gAAdboMNtMSZbYxksT1Sz sonKFASALnE+RDEa3VVic/oLMMYXVjYNZxLzYvAJJrXbqaB1A70xHVnLvAUenE4d2wP9 zqomhPynDDRjlXHOmxtftIe/9+HMJCHsfJPuOB6dfnni2AqbfAwFnXjtJvxM5l/Z9sXJ 1w4Q== 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 jz2si1702124ejb.140.2021.03.11.04.06.55; Thu, 11 Mar 2021 04:07:17 -0800 (PST) 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 S233020AbhCKMGD (ORCPT + 99 others); Thu, 11 Mar 2021 07:06:03 -0500 Received: from foss.arm.com ([217.140.110.172]:34024 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232638AbhCKMFh (ORCPT ); Thu, 11 Mar 2021 07:05:37 -0500 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 28F17ED1; Thu, 11 Mar 2021 04:05:37 -0800 (PST) Received: from e113632-lin.cambridge.arm.com (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 94A6A3F793; Thu, 11 Mar 2021 04:05:35 -0800 (PST) From: Valentin Schneider To: linux-kernel@vger.kernel.org Cc: Lingutla Chandrasekhar , Peter Zijlstra , Ingo Molnar , Vincent Guittot , Dietmar Eggemann , Morten Rasmussen , Qais Yousef , Quentin Perret , Pavan Kondeti , Rik van Riel Subject: [PATCH v3 1/7] sched/fair: Ignore percpu threads for imbalance pulls Date: Thu, 11 Mar 2021 12:05:21 +0000 Message-Id: <20210311120527.167870-2-valentin.schneider@arm.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210311120527.167870-1-valentin.schneider@arm.com> References: <20210311120527.167870-1-valentin.schneider@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Lingutla Chandrasekhar In load balancing, when balancing group is unable to pull task due to ->cpus_ptr constraints from busy group, then it sets LBF_SOME_PINNED to lb env flags, as a consequence, sgc->imbalance is set for its parent domain level. which makes the group classified as imbalance to get help from another balancing cpu. Consider a 4-CPU big.LITTLE system with CPUs 0-1 as LITTLEs and CPUs 2-3 as Bigs with below scenario: - CPU0 doing newly_idle balancing - CPU1 running percpu kworker and RT task (small tasks) - CPU2 running 2 big tasks - CPU3 running 1 medium task While CPU0 is doing newly_idle load balance at MC level, it fails to pull percpu kworker from CPU1 and sets LBF_SOME_PINNED to lb env flag and set sgc->imbalance at DIE level domain. As LBF_ALL_PINNED not cleared, it tries to redo the balancing by clearing CPU1 in env cpus, but it don't find other busiest_group, so CPU0 stops balacing at MC level without clearing 'sgc->imbalance' and restart the load balacing at DIE level. And CPU0 (balancing cpu) finds LITTLE's group as busiest_group with group type as imbalance, and Bigs that classified the level below imbalance type would be ignored to pick as busiest, and the balancing would be aborted without pulling any tasks (by the time, CPU1 might not have running tasks). It is suboptimal decision to classify the group as imbalance due to percpu threads. So don't use LBF_SOME_PINNED for per cpu threads. Signed-off-by: Lingutla Chandrasekhar [Use kthread_is_per_cpu() rather than p->nr_cpus_allowed] Signed-off-by: Valentin Schneider --- kernel/sched/fair.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 2e2ab1e00ef9..83aea97fbf22 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7565,6 +7565,10 @@ int can_migrate_task(struct task_struct *p, struct lb_env *env) if (throttled_lb_pair(task_group(p), env->src_cpu, env->dst_cpu)) return 0; + /* Disregard pcpu kthreads; they are where they need to be. */ + if ((p->flags & PF_KTHREAD) && kthread_is_per_cpu(p)) + return 0; + if (!cpumask_test_cpu(env->dst_cpu, p->cpus_ptr)) { int cpu; -- 2.25.1