Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp4349329ybg; Tue, 29 Oct 2019 05:57:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqyI4NwObzf/IMRPJ8WobFEfwc9QZxjXGVKFpIXjGgAfVxcDNW1YAB7LiFZ0fC3hUsMqHey8 X-Received: by 2002:a17:906:2584:: with SMTP id m4mr3165128ejb.287.1572353856471; Tue, 29 Oct 2019 05:57:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572353856; cv=none; d=google.com; s=arc-20160816; b=LOGjDi8x1vXKlLnqCSGOi9resfySEz2ZTJ7k0U45kjtalCguHeBCsQvKKuMaIYnpV2 WY+51SWD97uXTlktJnKa+nC7fqmBcvvZ9N1Rnzb4VZe2Er+VjOgPXyjWxnIPT5100GTe jlcQf5WdFLdLQCxdAT6vONd5tAOFWALYrHHMs+LmN60hBgKGLx8OwAr38CzDJ1wgS27r POtUrLyGPQw18jfsuabeUV+OdNXVG0iBigWwv60Ll4hfztLxD//+ad2nJPTZIp5kgX/C egcTsDz4BsZ30iSAfGhNgXKpo737b/iElVliWM2ms9JA8OEodU4tiiE4Bk+7i+7qCauo NloA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=iyC7yE5Zia5wjA+b3r/7nOVhr/nMlkQqP2NCwFPVhd4=; b=vFkOACaswfkC/IG+YIb6sTyN7/HVxoWzXuaTGa4e1bNdsB6gC57hjWq6FxF+/OeFiv xKpIxN9SNdw8myhmdQdfDOelyxx/CuDz2nlfhUTfwO5EZEsN6w8nm7JRCtLnLphtltOx Xi+emqU03SjXSp/1jTyPIxl64OYV0Ro3Wn3Qiv0iTJ91X4ymaYrh3cBWiHMELss+3MnQ NFBCyTnihePu9BZPX76IBDaAFjyhAyJSycZaIpK379zfDdcmvDdhvB7XTVAmOeUCk10u hcvTrR/yxEvQi/ujurPv41thCx5UrkPWKtYGYs0gQVi5WF96zvRRMK+lUetvOBx3367c Jpgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ahjtDDP9; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f11si10314059edb.100.2019.10.29.05.57.12; Tue, 29 Oct 2019 05:57:36 -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; dkim=pass header.i=@linaro.org header.s=google header.b=ahjtDDP9; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388006AbfJ2Myi (ORCPT + 99 others); Tue, 29 Oct 2019 08:54:38 -0400 Received: from mail-lf1-f66.google.com ([209.85.167.66]:39964 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729253AbfJ2Myi (ORCPT ); Tue, 29 Oct 2019 08:54:38 -0400 Received: by mail-lf1-f66.google.com with SMTP id f4so4438035lfk.7 for ; Tue, 29 Oct 2019 05:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iyC7yE5Zia5wjA+b3r/7nOVhr/nMlkQqP2NCwFPVhd4=; b=ahjtDDP93botL/npzK6iP0iXdCdOLn32mOXHEjBGFtbQMGKtcWtlE+IS5ZWtLJ7pT0 F2aFfEq8Gn6S/gyR2+9YNq2+0CC3tm6JwKAP2+j+p2x1yjWBTFJWKBc3vza418nnG9GT 1bBO0Pujh56xJjkUUTHxc09oCwvo7zEO1iiFC8GhLGzA7W/Eof9Pd+mJZPLk5m18wn5Z UGqe4hwR3G5+DEmOv9D9WtzNNCuZ4JJadOxc8xRl+xUEVOE1Kr7Y0AjY4z6vK5j5PqTE khnaiC3qgdWxevSCZbI9fmzVKh1VI83sOWDkwsOUTvnU247+DRd2J6rYZLIVAUaCdLjr TF2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iyC7yE5Zia5wjA+b3r/7nOVhr/nMlkQqP2NCwFPVhd4=; b=jihVynE4i44ng8E3gSl35+/79lRo3X9bGBgpcQPA2pFGsM/fbs7NsFkwOe/65Yy84A RSY4cqv27+vM+YbSe1sbAcdWF59MId5g5WDT9qqGxndlFqIYmYpEjWkqIiAUy+fo6qQ9 ScOBTuvbp0D9pujihdZXsnWlurKVfcNSTQR+dzMEor89kzg4oUOhOvrwI0OmntXqzOO3 NSWhnjxDRamhXRYZOtjMCPSSWGGF/bNXyWb24TlLtWZdzBUxbgpRsc21okaZh+zPNAiQ 4TBvc74GUh2armxbV+Mp9KPerrwihiW4yITWCxtnCTsysGd9l40mgkesufyIMRfSo1y4 zGpQ== X-Gm-Message-State: APjAAAWYm+iGlaoG8QjQ0coeqzca7uvLIPRMrI1At6JhzzIqRPdotpUk xXXCUw1TM6+VOjACwzDK6XE8thQwtMfUAyM0ZLQBRoXN X-Received: by 2002:a19:ca13:: with SMTP id a19mr2333981lfg.133.1572353675805; Tue, 29 Oct 2019 05:54:35 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <20191029124630.ivfbpenue3fw33qt@e107158-lin.cambridge.arm.com> From: Vincent Guittot Date: Tue, 29 Oct 2019 13:54:24 +0100 Message-ID: Subject: Re: [PATCH v2] sched: rt: Make RT capacity aware To: Qais Yousef Cc: Ingo Molnar , Peter Zijlstra , Steven Rostedt , Juri Lelli , Dietmar Eggemann , Ben Segall , Mel Gorman , linux-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 29 Oct 2019 at 13:46, Qais Yousef wrote: > > On 10/29/19 13:20, Vincent Guittot wrote: > > > > Making big cores the default CPUs for all RT tasks is not a minor > > > > change and IMO locality should stay the default behavior when there is > > > > no uclamp constraint > > > > > > How this is affecting locality? The task will always go to the big core, so it > > > should be local. > > > > local with the waker > > You will force rt task to run on big cluster although waker, data and > > interrupts can be on little one. > > So making big core as default is far from always being the best choice > > This is loaded with assumptions IMO. AFAICT we don't know what's the best > choice. > > First, the value of uclamp.min is outside of the scope of this patch. Unless > what you're saying is that when uclamp.min is 1024 then we should NOT choose a > big cpu then there's no disagreement about what this patch do. If that's what > you're objecting to please be more specific about how do you see this working > instead. My point is that this patch makes the big cores the default CPUs for RT tasks which is far from being a minor change and far from being an obvious default good choice > > If your objection is purely based on the choice of uclamp.min then while > I agree that on modern systems the little cores are good enough for the > majority of RT tasks in average Android systems. But I don't feel confident to > reach this conclusion on low end systems where the little core doesn't have > enough grunt in many cases. So I see the current default is adequate and the > responsibility of further tweaking lies within the hands of the system admin. > > -- > Qais Yousef