From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EBD3C10F26 for ; Tue, 19 Jan 2021 18:28:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5A17F20706 for ; Tue, 19 Jan 2021 18:28:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390637AbhASRB5 (ORCPT ); Tue, 19 Jan 2021 12:01:57 -0500 Received: from foss.arm.com ([217.140.110.172]:40152 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388905AbhASQ4m (ORCPT ); Tue, 19 Jan 2021 11:56:42 -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 E5C9BD6E; Tue, 19 Jan 2021 08:55:53 -0800 (PST) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 00E573F66E; Tue, 19 Jan 2021 08:55:52 -0800 (PST) From: Valentin Schneider To: Vincent Guittot Cc: Qais Yousef , "Peter Zijlstra \(Intel\)" , Dietmar Eggemann , linux-kernel , Morten Rasmussen Subject: Re: [PATCH] sched/eas: Don't update misfit status if the task is pinned In-Reply-To: References: <20210119120755.2425264-1-qais.yousef@arm.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/26.3 (x86_64-pc-linux-gnu) Date: Tue, 19 Jan 2021 16:55:43 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19/01/21 15:19, Vincent Guittot wrote: > On Tue, 19 Jan 2021 at 14:54, Valentin Schneider > wrote: >> On 19/01/21 14:34, Vincent Guittot wrote: >> >> - if (!p) { >> >> + if (!p || p->nr_cpus_allowed == 1) { >> > >> > Side question: What happens if there is 2 misfit tasks and the current >> > one is pinned but not the other waiting one >> > >> >> update_misfit_status() is called either on the current task (at tick) or >> on the task picked by pick_next_task_fair() - i.e. CFS current or >> about-to-be-current. >> >> So if you have 2 CPU hogs enqueued on a single LITTLE, and one of them >> is pinned, the other one will be moved away either via regular load > > This doesn't seem reliable because it uses load or nr_running > Right >> balance, or via misfit balance sometime after it's picked as the next >> task to run. >> >> Admittedly that second case suffers from unfortunate timing mostly >> related to the load balance interval. There was an old patch in the >> Android stack that would reduce the balance interval upon detecting a > > Shouldn't we keep track of enqueue misfit tasks instead ? > That might help. This being CFS however, the maintenance of it might prove prohibitive. I faintly recall having concerns about expanding the misfit logic to non-current tasks, but nothing comes to mind right now... Historically (before PELT time scaling) I think it wasn't possible to have a steady state with more than one misfit task on a rq, as two similar CPU hogs would end up with a utilization value of at most half the CPU's capacity. If those were at e.g. opposite ends of the NICE spectrum, if one would be flagged as misfit then the other wouldn't (can't have two slices greater than 80%!) I *think* that's still true with timescaling, but then we did add the uclamp stuff to make tasks look bigger than they are... >> misfit task to "accelerate" its upmigration; this might need to be >> revisited... >> >> >> rq->misfit_task_load = 0; >> >> return; >> >> } >> >> -- >> >> 2.25.1 >> >>