Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1947392ybv; Fri, 14 Feb 2020 08:41:50 -0800 (PST) X-Google-Smtp-Source: APXvYqy8Px4SraT+YSrrVD4DWIOelJrLqKlmPWMMag7RxNgu+Ku8b0D0a6v9BDaa1z/gw+j4H+7/ X-Received: by 2002:a05:6830:13ca:: with SMTP id e10mr3011391otq.267.1581698510200; Fri, 14 Feb 2020 08:41:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581698510; cv=none; d=google.com; s=arc-20160816; b=Wib+ukmGBzzQEZqQAs9hPSHkfcLjycE0GZa0C9l5deMolfuPMZUMxA5tXNXopHrLd8 NoZdgtVMdrrKjx3h623sK9FrDvC9NlqBcAMR6p1UAUai4LqpnWD5BbL9e+/Snx6/MmJv tCHbO70m2MQg2IM9sSvBR8rA8Cn3rkt9LbfOMzwVG1GUwpNqlP8vjaDz/eUc2rWMveEg 94rQfIhB2ra5u1Tc+JfKi42vvgDELiSc0Gu0jV3ryVX8CiTFyVqq4woHt9YYDh0f+lF2 AAlpbrGM2x4N5lR0794W5EJud/fzpxkq6beFE9pnqy/wNDmiHEq/F1HjW3qbHKw+KhHc 7Gqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=7UThtJvtTKEBp6XHO+5Dv86ZL2zYC4KHxoneVqDni2Q=; b=cFHWYAjTYQocWeLsLPNiHA+pvqLqoi4uaoR7hu/KoPSVcOpHsVEjA9WtOzxwZloEEn 9VxR0gC77JpPDh7hY/fRjl4PK5mJsxtS59Ss9XXJACIjupvHXIwa5uUnclNLoSTz/2ul OuqJpQYAYfUs23LWr2IVKkkx+W9snwqeVSWcTWS9HReEdLpzju4YdPusCy4H4xGXXZZX ugN3VvcTdEoYopiS2bvtTmNSVPT4TMnVVXgIabfkDPh00OhI4EVpJ657mqi+mvgQxITa vzxaFGjy4NewdgqYf2VCr6m2HUqywrIp7J23h6C/YCmXhexlU1+Px/0tIaTZIUJNaW4F xhRw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x11si2940504otp.285.2020.02.14.08.41.38; Fri, 14 Feb 2020 08:41:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405909AbgBNQkD (ORCPT + 99 others); Fri, 14 Feb 2020 11:40:03 -0500 Received: from foss.arm.com ([217.140.110.172]:39232 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405838AbgBNQj6 (ORCPT ); Fri, 14 Feb 2020 11:39:58 -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 A64FA328; Fri, 14 Feb 2020 08:39:57 -0800 (PST) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 38FDC3F68E; Fri, 14 Feb 2020 08:39:56 -0800 (PST) From: Qais Yousef To: Ingo Molnar , Peter Zijlstra , Steven Rostedt , Pavan Kondeti , Dietmar Eggemann Cc: Juri Lelli , Vincent Guittot , Ben Segall , Mel Gorman , linux-kernel@vger.kernel.org, Qais Yousef Subject: [PATCH 0/3] RT Capacity Awareness Improvements Date: Fri, 14 Feb 2020 16:39:46 +0000 Message-Id: <20200214163949.27850-1-qais.yousef@arm.com> X-Mailer: git-send-email 2.17.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Pavan has pointed out an oversight in the first implementation where we don't fallback to another unfitting CPU if we are already running on unfitting one. This also stirred discussion around handling downmigration from fitting to unfitting CPU. https://lore.kernel.org/lkml/20200203111451.0d1da58f@oasis.local.home/ Patch 1 adds the missing fallback when a fitting CPU wasn't found, reported by Pavan. Patch 2 allows downmigration in the pull case and marks the CPU as overloaded as suggested by Steve. Patch 3 fixes the condition in select_task_rq_rt() in case the new_cpu and the task priorities are the *same*. The series is based on Linus/master v5.6-rc1. I ran the following test cases, the results of which can be found in [1] Each test was run 3 times to demonstrate repeatability of the result. The tests were ran on Juno-r2, which has 6 CPUs. CPUs [0, 3-5] are Littles and CPUs [1-2] are Bigs. By default RT tasks are boosted to max capacity, so no work was done to modify that. ie: rt_task->uclamp_min = 1024 for all running tests. 1. 6 RT Tasks * 2 Tasks always end up on the big cores * The rest end up on the little cores with migration among them happening (it didn't before) 2. 2 RT Tasks * We can see they always end up on the 2 big cores 3. 4 RT Tasks * Results similar to 1 4. 4 RT Tasks affined to little cores * The tasks run on the little cores with some migration as expected [1] https://gist.github.com/qais-yousef/bb99bdd912628489408a5edae33f85e1 Qais Yousef (3): sched/rt: cpupri_find: implement fallback mechanism for !fit case sched/rt: allow pulling unfitting task sched/rt: fix pushing unfit tasks to a better CPU kernel/sched/cpupri.c | 157 +++++++++++++++++++++++++++--------------- kernel/sched/rt.c | 50 ++++++++++---- 2 files changed, 139 insertions(+), 68 deletions(-) -- 2.17.1