Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4028568ybl; Mon, 3 Feb 2020 11:08:39 -0800 (PST) X-Google-Smtp-Source: APXvYqxadAtGUTsfOJLTPpf+jDb+wgoRlifn9jj9cfGMEQYBPM7bbXUhO3uWRYKEflZmZ3lEiy+J X-Received: by 2002:a05:6808:3ba:: with SMTP id n26mr395186oie.62.1580756919799; Mon, 03 Feb 2020 11:08:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580756919; cv=none; d=google.com; s=arc-20160816; b=uBkSX6pbKb43hS2xErBw7W51zOtDVQVsGj54xq9UxIgDO9vkSYnFN9CY8rI4pYF69d +h+W+91E11YLf65m6vz+ZyNisy0eSuCQLaIymEsYFAKktpWBVni536rnQksVpvCq7wh4 bJ/WBJTx8FyNVxIC6SvvfCX2o8yXAGuZel0ceLB1flVK9fq/xDCqwH9WJNTLYjBI8KIs mWAu6PhLZwIjHS0UWgKRhd+dLSMEc7ZKf0m9Zx06fnXYgpiFWyw7Obfsxzs9SE0Ir5BE S37+LT686Fjc6WZ5xw8PH+eXrlTFyzjOvGqWOHqceuoeXSph1NMBw7JEpp4i+r4J0+YU wajA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=0Z9aT2ww8SYwFjDxpJ09NqVdjIenYAPoFly/mXH9P3I=; b=P4Z2a818zt4QAH6taoRew3lM2l+WYVAWXZehq2LL9g+GWkxGpw6aqPz3gX+SHYtuMv VgQ1gUrE2+xDcW+/xdhDC0ObiM5IekPNhmZq359l1AIzgSyWhf3SrEu1C2PYWfdvoUAi MFx1fMZATINtWB0icPvP7lQExwwoSVTQJS0Zx2PiAk5BJkvGSe/hEyEqA5zl/relQQtZ /pq1TZR7rgvxU0sEV+6OETRCUSi7SSSd2Q16X5YK9cRNi/cs8GxsqFUcTxBLI4PPQhox U7qo7grOqDqSEjlpvaiN9n+UT/xzGel2xxlfk0aF3Fq3MeE/JzGpBBegEeDID7qqBlvC zO/Q== 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 t192si8533169oif.75.2020.02.03.11.08.27; Mon, 03 Feb 2020 11:08:39 -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 S1728679AbgBCRPF (ORCPT + 98 others); Mon, 3 Feb 2020 12:15:05 -0500 Received: from foss.arm.com ([217.140.110.172]:56462 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729002AbgBCRPE (ORCPT ); Mon, 3 Feb 2020 12:15:04 -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 095EE30E; Mon, 3 Feb 2020 09:15:04 -0800 (PST) Received: from [10.1.194.46] (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 859383F52E; Mon, 3 Feb 2020 09:15:02 -0800 (PST) Subject: Re: [PATCH v2] sched: rt: Make RT capacity aware To: Steven Rostedt , Qais Yousef Cc: Pavan Kondeti , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , LKML References: <20191009104611.15363-1-qais.yousef@arm.com> <20200131100629.GC27398@codeaurora.org> <20200131153405.2ejp7fggqtg5dodx@e107158-lin.cambridge.arm.com> <20200203142712.a7yvlyo2y3le5cpn@e107158-lin> <20200203111451.0d1da58f@oasis.local.home> From: Valentin Schneider Message-ID: <8868c5cf-e3f4-04e1-e071-0476ac813191@arm.com> Date: Mon, 3 Feb 2020 17:15:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200203111451.0d1da58f@oasis.local.home> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/02/2020 16:14, Steven Rostedt wrote: > On Mon, 3 Feb 2020 14:27:14 +0000 > Qais Yousef wrote: > >> I don't see one right answer here. The current mechanism could certainly do >> better; but it's not clear what better means without delving into system >> specific details. I am open to any suggestions to improve it. > > The way I see this is that if there's no big cores available but little > cores are, and the RT task has those cores in its affinity mask then > the task most definitely should consider moving to the little core. The > cpu_find() should return them! > > But, what we can do is to mark the little core that's running an RT > task on a it that prefers bigger cores, as "rt-overloaded". This will > add this core into the being looked at when another core schedules out > an RT task. When that happens, the RT task on the little core will get > pulled back to the big core. > That sounds sensible enough - it's also very similar to what we have for CFS, labeled under "misfit tasks" (i.e. tasks that are "too big" for LITTLEs). > > Note, this will require a bit more logic as the overloaded code wasn't > designed for migration of running tasks, but that could be added. > I haven't adventured too much within RT land, but FWIW that's what we use the CPU stopper for in CFS (see active_load_balance_cpu_stop()). > -- Steve >