Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1538638pxb; Thu, 4 Feb 2021 16:07:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJyjrxQL6iSavwBg5JJN+tHIsFRtI70u/UxWrUdL8Kxbow/dwOHeivk+jKfwJgfZQCeHKkrQ X-Received: by 2002:a17:906:c049:: with SMTP id bm9mr1412173ejb.535.1612483668921; Thu, 04 Feb 2021 16:07:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612483668; cv=none; d=google.com; s=arc-20160816; b=oUga82bdoscuCuNMo0DXmsP+dwecp5uFIH96DifN/7J20cbdIAr32NrruMo05lLKTj UHu1pxQ6eapt68DgFLTybhfZT09/3VMZdFClKfvJ8ypguUNGR3AMBw0aPKruejYYa3Ne KP62AyTByPtxZD+U3vaMmuKH7I6zoJBCBAxVycjiORcFgZyHifHqCg92A3x2yI7pj08j qn0tLHokL+TmNnVHHhaapW6AQImeeK4p8i8Vn4CQbazPGIMNeaMl1lj34wVL/4Jh2P5T BcNC7HSfzYyTRO2bpuPh68TvUuX0lX2IkSoRipsyfscA1xi9KZfOj0co/R7cWQ3ncYvi B+wg== 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:user-agent :references:in-reply-to:subject:cc:to:from; bh=jIYlmOhpILJuuQuiWhvM6pmeACJD3KskBZFLuHELDjA=; b=ot3DAUw/PISFZLmquXMP/wiAftY6rR34f0AJDCiT0o+spFyYuoaAo6RVQA7W0KbeQr 0Hl24cYz/KWe8GI79Yz6RKZ49MoGdspQqSPYnQf73xFqrK2MNvA2XSBd/kuiC/Vj4rZC 0O7G4VaxDiyAcdy72xHBg3yDmjqKeZHqgjbKMHf+nwT++oyMcLe+9hd6BoH1SetIFDLe n9TcyIRkcy76h0b5mP2QrAstGK9MuD3ZyCH07y+fkiNQ7avmEOKe4l5ncFKP8reCwuQW N5bXzqmGS4V0QLVSwTj0b5FgHVJxgAZ/aoLNroSokfHFJNlGH96m9BhFKuiBrv7qZY+A O6BA== 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 f21si1790151edw.164.2021.02.04.16.07.24; Thu, 04 Feb 2021 16:07:48 -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 S235907AbhBDMgy (ORCPT + 99 others); Thu, 4 Feb 2021 07:36:54 -0500 Received: from foss.arm.com ([217.140.110.172]:57668 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235711AbhBDMgv (ORCPT ); Thu, 4 Feb 2021 07:36:51 -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 2FC0AD6E; Thu, 4 Feb 2021 04:36:06 -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 D26A33F73B; Thu, 4 Feb 2021 04:36:04 -0800 (PST) From: Valentin Schneider To: Dietmar Eggemann , Qais Yousef Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar , Vincent Guittot , Morten Rasmussen , Quentin Perret , Pavan Kondeti , Rik van Riel Subject: Re: [PATCH 0/8] sched/fair: misfit task load-balance tweaks In-Reply-To: <66efcfb1-d6ee-248a-e337-d690cda1bb5a@arm.com> References: <20210128183141.28097-1-valentin.schneider@arm.com> <20210203151400.ommltjjyuok4yj5e@e107158-lin> <66efcfb1-d6ee-248a-e337-d690cda1bb5a@arm.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/26.3 (x86_64-pc-linux-gnu) Date: Thu, 04 Feb 2021 12:36:02 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/02/21 13:03, Dietmar Eggemann wrote: > How did you verify the benefit of these changes? > > It's clear that you need a platform with capacity_orig diffs <20% > between CPU types (like Pixel4 - SD855 (4x261, 3x871, 1x1024) or QC's > RB5 platform - SD865 (4x284, 3x871, 1*1024)) but which > benchmark/testcase did you use? Benchmark is the usual culprit: https://lisa-linux-integrated-system-analysis.readthedocs.io/en/master/kernel_tests.html#lisa.tests.scheduler.misfit.StaggeredFinishes This test spawns 1 CPU hog per CPU, and screams whenever a CPU of capacity X is running a hog while another CPU of capacity Y > X has been idling for "too long" (a few ms). IOW it makes sure upmigration happens in a timely manner. Some of the test platforms (Juno (4+2 big.LITTLE), HiKey960 (4+4 big.LITTLE)) show some improvements due to the last 2 patches. As for systems with CPUs in the [819-1024] "deadzone", Ionela's been kindly running said test on said RB5, and the upmigrations look just fine with the patches applied.