Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3385491ybc; Mon, 25 Nov 2019 13:39:40 -0800 (PST) X-Google-Smtp-Source: APXvYqyrrfHwkybMP73zpxBz1paRrSEYXKtRQlIbGGEWFKMeDRoXPf+FOk4hxAkp9C9Jvbee0Crf X-Received: by 2002:a17:906:c44f:: with SMTP id ck15mr39061594ejb.7.1574717980521; Mon, 25 Nov 2019 13:39:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574717980; cv=none; d=google.com; s=arc-20160816; b=jvAblbuRMEa6A2sQCQd/iI/58KJnPRGJLLzg7XxRUaAwlNOnps9Rr2pwq6vtkqY24t SgIYcvwrtjHG3utRY4+R2Vh9u92blxjyvR6Fgoes1w3a8Nze5tzC0Jrb/igM38JVU5lJ l/aGMWZ8TuNP57DzAvV8ev3D+KRrGa8DpWwaiRhdeNHB84wTZvrLJdCRpmh8s9E8w+0k NaWnQiJSy2KjTClht+ZKBp6WM/qDm7Bp6OMAGMLi9xHUTQI8lGrvlhInTDEm34m/n+VH WTXhsL5oQzYLF2Fli8h3nsm1gUMuH0gJXJCk2o9De4TNyLS8yMiEEYi1DpT70/4gmXhd Jbig== 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:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=8SNTSx6YuVDsy8MzjhA8QobdKmDDcdWuwKW3h0idWjs=; b=Zw1yA7jn8TDq1psAL6WZk0QbOTd0JOxEHbsRAc+M0gSOIG78ga8kADccrfRu6btkGF fbmKbn3wQSWqBp1PVWKA4TlEIyEFBCwAZr6Qj/a6KgJWYkGG3wnZ7n1OUnNv1SCyoxH0 Gp0B4ugJ0xOWp/KBBiAqX62HeyczM+iuHLSqSORBhQVT0HqkkQnIuBB5MNuHtubFfPR7 zTUTCADdRvn7y6ZVGUHUeiH4GMkF11oJFTC9n5cm2HKfOI3XkrXoVvbJpIN/gidzr/Zu sw9qS1epOvzoU82kwIJQ/POsZNZ98I88FRJ8hzeu2pGdvWrlbhtCsj5ZeXHzxvAJ5gHk BtRg== 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 oq2si5540265ejb.402.2019.11.25.13.39.05; Mon, 25 Nov 2019 13:39:40 -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 S1726094AbfKYVgx (ORCPT + 99 others); Mon, 25 Nov 2019 16:36:53 -0500 Received: from mail.kernel.org ([198.145.29.99]:58770 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725945AbfKYVgx (ORCPT ); Mon, 25 Nov 2019 16:36:53 -0500 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0534D20706; Mon, 25 Nov 2019 21:36:51 +0000 (UTC) Date: Mon, 25 Nov 2019 16:36:50 -0500 From: Steven Rostedt To: Qais Yousef Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] sched: rt: Make RT capacity aware Message-ID: <20191125163650.6a624fee@gandalf.local.home> In-Reply-To: <20191009104611.15363-1-qais.yousef@arm.com> References: <20191009104611.15363-1-qais.yousef@arm.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sorry for the very late response... On Wed, 9 Oct 2019 11:46:11 +0100 Qais Yousef wrote: > ATM the uclamp value are only used for frequency selection; but on > heterogeneous systems this is not enough and we need to ensure that the > capacity of the CPU is >= uclamp_min. Which is what implemented here. Is it possible that the capacity can be fixed, where the process can just have a cpu mask of CPUs that has the capacity for it? Not that this will affect this patch now, but just something for the future. > > capacity_orig_of(cpu) >= rt_task.uclamp_min > > Note that by default uclamp.min is 1024, which means that RT tasks will > always be biased towards the big CPUs, which make for a better more > predictable behavior for the default case. > > Must stress that the bias acts as a hint rather than a definite > placement strategy. For example, if all big cores are busy executing > other RT tasks we can't guarantee that a new RT task will be placed > there. > > On non-heterogeneous systems the original behavior of RT should be > retained. Similarly if uclamp is not selected in the config. > > Signed-off-by: Qais Yousef Reviewed-by: Steven Rostedt (VMware) -- Steve