Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp631076ybx; Wed, 30 Oct 2019 02:28:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqyY3UhEZDm4ZSEnBJxe8C0DpBP3iz733AB7jqVJ6w4FVkmteuRwikom70S9l2wAbAhZoNL7 X-Received: by 2002:a17:906:76c3:: with SMTP id q3mr7850652ejn.199.1572427684694; Wed, 30 Oct 2019 02:28:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572427684; cv=none; d=google.com; s=arc-20160816; b=ENxGy2nK/2n3ovPpJ8/UFGFXhFqqti89NcMPMkmXzUyXqtCKOlnue3B6w8xcUzxyNR dsh1awomHE0fKEVOmWLPDwwuR11EcuvZ2UVr+0O4Lnln8uGBkDdMamPDtsIS5Oe9999L 52Zk1QVB9qYh1D7adpcQwc0UjZfss8CckyrYw/WqC8J39zT+8m+H7SUhRTYKhR7VHLmL 5gQdqysib9ULRxuq1+F9p4clLKhqItQNPlVw7MH4uddjzh31FLxuMREdb6JyosWP/yhC VJFojSH/rc8JF5mKZQ0ZjFuEQELiFKFopSwv2Fmpeu7lgLDR0lb4M45LE8XD4OzOysKx 7t/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=FrNBuUrJzjiKCERgcvnU4V+1OHFfqe6KHFTf7iUO0ac=; b=ylAoHC406L3/9IgnvoiXLd3DXDHoh0UsrCnLFoaup98zHvZZXQ0H36X6vBJsC8a7Ff 6jDZuhchbGMT5BERCxY35YLvUU3sMckWB8uhRTZjMiAn3w7pLX5a15OLQg6ZhSh3Z8Mk W8M3SOwYAbv7A24zWWNqfa1bC0wEFEPQq1e01s9fdTTMLXUAV/H+Y9Ta8jmuoiM1ySmQ n1v9xEncTkrZucmSY2Bu6Lwvkbpc5N95FybeFXS833SNnjN1icp0lOL+Z92srjuFQ66H PNDCuQ8lR3+v6VfiUTVqeqRjm7NRffOMQgZUOtAbIqrzaZOO1rCDfzM4htVKz80xsU1F 50YQ== 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 o57si1008875edc.240.2019.10.30.02.27.36; Wed, 30 Oct 2019 02:28:04 -0700 (PDT) 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 S1726187AbfJ3J0s (ORCPT + 99 others); Wed, 30 Oct 2019 05:26:48 -0400 Received: from foss.arm.com ([217.140.110.172]:32924 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726028AbfJ3J0s (ORCPT ); Wed, 30 Oct 2019 05:26:48 -0400 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 1B80E1F1; Wed, 30 Oct 2019 02:26:47 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BB2F63F6C4; Wed, 30 Oct 2019 02:26:45 -0700 (PDT) Date: Wed, 30 Oct 2019 09:26:43 +0000 From: Qais Yousef To: Vincent Guittot Cc: Patrick Bellasi , Ingo Molnar , Peter Zijlstra , Steven Rostedt , Juri Lelli , Dietmar Eggemann , Ben Segall , Mel Gorman , linux-kernel Subject: Re: [PATCH v2] sched: rt: Make RT capacity aware Message-ID: <20191030092642.pxmc3o2lvphjs4mb@e107158-lin.cambridge.arm.com> References: <20191009104611.15363-1-qais.yousef@arm.com> <20191029110224.awoi37pdquachqtd@e107158-lin.cambridge.arm.com> <20191029114824.2kb4fygxxx72r3in@e107158-lin.cambridge.arm.com> <20191029124630.ivfbpenue3fw33qt@e107158-lin.cambridge.arm.com> <20191029203619.GA7607@darkstar> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/30/19 09:04, Vincent Guittot wrote: > On Tue, 29 Oct 2019 at 21:36, Patrick Bellasi > wrote: > > Some time ago we agreed that going to MAX_OPP for RT tasks was > > "mandatory". That was defenitively a big change, likely much more > > impacting than the one proposed by this patch. > > > > On many mobile devices we ended up pinning RT tasks on LITTLE cores > > (mainly) to save quite a lot of energy by avoiding the case of big > > CPUs randomly spiking to MAX_OPP just because of a small RT task > > waking up on them. We also added some heuristic in schedutil has a > > "band aid" for the effects of the aforementioned choice. > > > > By running RT on LITTLEs there could be also some wakeup latency > > improvement? Yes, maybe... would be interesting to have some real > > HW *and* SW use-case on hand to compare. > > > > However, we know that RT is all about "latency", but what is a bit > > more fuzzy is the definition of "latency": > > > > A) wakeup-latency > > From a scheduler standpoint it's quite often considered as the the > > time it takes to "wakeup" a task and actually start executing its > > instructions. > > > > B) completion-time > > From an app standpoint, it's quite often important the time to > > complete the task activation and go back to sleep. > > > > Running at MAX_OPP looks much more related to the need to complete > > fast than waking up fast, especially considering that that decision > > You will wake up faster as well when running at MAX_OPP because > instructions will run faster or at least as fast. That being said, > running twice faster doesn't mean at all waking up twice faster but > for sure it will be faster although the gain can be really short. > Whereas running on a big core with more capacity doesn't mean that you > will wake up faster because of uarch difference. > I agree that "long" running rt task will most probably benefit from > big cores to complete earlier but that no more obvious for short one. Idle states and other power management features are a known source of latency. This latency changes across hardware all the time and RT people are accustomed to test against this. Android has a wakelock which AFAIR disabled deep sleep because on some sections the wakeup latency can hinder throughput for some apps. So it's a known problem outside RT universe too. > > > was taken looking mainly (perhaps only) to SMP systems. > > > > On heterogeneous systems, "wakeup-latency" and "completion-time" are > > two metrics which *maybe* can be better served by different cores. > > However, it's very difficult to argument if one metric is more > > important than the other. It's even more difficult to quantify it > > because of the multitide of HW and SW combinations. > > That's the point of my comment, choosing big cores as default and > always best choice is far from being obvious. It's consistent and deterministic unlike the current situation of it depends on your luck. What you get across boots/runs is completely random and this is worse than what this patch offers. The default for Linux has always been putting the system at the highest performance point by default. And this translates to the biggest CPU at the highest frequency. It's not ideal but consistent. This doesn't prevent people from tweaking their systems to get what they want. > And this patch changes the default behavior without study of the > impact apart from stating that this should be ok Without this patch there's no way for an RT task to guarantee a minimum performance requirement. I don't think there's a change of the default behavior because without this patch we could still end up on a big CPU. And you're stating that the difference between wakeup time in big cores and little cores is a problem. And as I stated several times this is a known source of latency that changes across systems and if somebody cares about idle state latencies then they probably looking at something beyond generic systems and need to tune it to guarantee a deterministic low latency behavior. I still don't see any proposed alternative to what should be the default behavior. -- Qais Yousef