From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D724C4363C for ; Wed, 7 Oct 2020 10:36:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CB9C920872 for ; Wed, 7 Oct 2020 10:36:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728058AbgJGKg6 (ORCPT ); Wed, 7 Oct 2020 06:36:58 -0400 Received: from foss.arm.com ([217.140.110.172]:41600 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727773AbgJGKg6 (ORCPT ); Wed, 7 Oct 2020 06:36:58 -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 6D14D11B3; Wed, 7 Oct 2020 03:36:57 -0700 (PDT) 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 1AEF33F71F; Wed, 7 Oct 2020 03:36:56 -0700 (PDT) Date: Wed, 7 Oct 2020 11:36:53 +0100 From: Qais Yousef To: Rob Clark Cc: dri-devel , linux-arm-msm , Tejun Heo , Tim Murray , Daniel Vetter , Rob Clark , open list , Steven Rostedt , "Peter Zijlstra (Intel)" Subject: Re: [PATCH v2 0/3] drm: commit_work scheduling Message-ID: <20201007103653.qjohhta7douhlb22@e107158-lin.cambridge.arm.com> References: <20200930211723.3028059-1-robdclark@gmail.com> <20201002110105.e56qrvzoqfioi4hs@e107158-lin.cambridge.arm.com> <20201005150024.mchfdtd62rlkuh4s@e107158-lin.cambridge.arm.com> <20201006105918.v3xspb6xasjyy5ky@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 10/06/20 13:04, Rob Clark wrote: > On Tue, Oct 6, 2020 at 3:59 AM Qais Yousef wrote: > > > > On 10/05/20 16:24, Rob Clark wrote: > > > > [...] > > > > > > RT planning and partitioning is not easy task for sure. You might want to > > > > consider using affinities too to get stronger guarantees for some tasks and > > > > prevent cross-talking. > > > > > > There is some cgroup stuff that is pinning SF and some other stuff to > > > the small cores, fwiw.. I think the reasoning is that they shouldn't > > > be doing anything heavy enough to need the big cores. > > > > Ah, so you're on big.LITTLE type of system. I have done some work which enables > > biasing RT tasks towards big cores and control the default boost value if you > > have util_clamp and schedutil enabled. You can use util_clamp in general to > > help with DVFS related response time delays. > > > > I haven't done any work to try our best to pick a small core first but fallback > > to big if there's no other alternative. > > > > It'd be interesting to know how often you end up on a big core if you remove > > the affinity. The RT scheduler picks the first cpu in the lowest priority mask. > > So it should have this bias towards picking smaller cores first if they're > > in the lower priority mask (ie: not running higher priority RT tasks). > > fwiw, the issue I'm looking at is actually at the opposite end of the > spectrum, less demanding apps that let cpus throttle down to low > OPPs.. which stretches out the time taken at each step in the path > towards screen (which seems to improve the odds that we hit priority > inversion scenarios with SCHED_FIFO things stomping on important CFS > things) So you do have the problem of RT task preempting an important CFS task. > > There is a *big* difference in # of cpu cycles per frame between > highest and lowest OPP.. To combat DVFS related delays, you can use util clamp. Hopefully this article helps explain it if you didn't come across it before https://lwn.net/Articles/762043/ You can use sched_setattr() to set SCHED_FLAG_UTIL_CLAMP_MIN for a task. This will guarantee everytime this task is running it'll appear it has at least this utilization value, so schedutil governor (which must be used for this to work) will pick up the right performance point (OPP). The scheduler will try its best to make sure that the task will run on a core that meets the minimum requested performance point (hinted by setting uclamp_min). Thanks -- Qais Yousef From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65E69C47095 for ; Wed, 7 Oct 2020 15:39:55 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F22E0216C4 for ; Wed, 7 Oct 2020 15:39:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F22E0216C4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9D9706E929; Wed, 7 Oct 2020 15:39:42 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by gabe.freedesktop.org (Postfix) with ESMTP id 22C326E8BB for ; Wed, 7 Oct 2020 10:36:58 +0000 (UTC) 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 6D14D11B3; Wed, 7 Oct 2020 03:36:57 -0700 (PDT) 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 1AEF33F71F; Wed, 7 Oct 2020 03:36:56 -0700 (PDT) Date: Wed, 7 Oct 2020 11:36:53 +0100 From: Qais Yousef To: Rob Clark Subject: Re: [PATCH v2 0/3] drm: commit_work scheduling Message-ID: <20201007103653.qjohhta7douhlb22@e107158-lin.cambridge.arm.com> References: <20200930211723.3028059-1-robdclark@gmail.com> <20201002110105.e56qrvzoqfioi4hs@e107158-lin.cambridge.arm.com> <20201005150024.mchfdtd62rlkuh4s@e107158-lin.cambridge.arm.com> <20201006105918.v3xspb6xasjyy5ky@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-Mailman-Approved-At: Wed, 07 Oct 2020 15:39:39 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rob Clark , "Peter Zijlstra \(Intel\)" , linux-arm-msm , open list , Tim Murray , Steven Rostedt , dri-devel , Tejun Heo Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 10/06/20 13:04, Rob Clark wrote: > On Tue, Oct 6, 2020 at 3:59 AM Qais Yousef wrote: > > > > On 10/05/20 16:24, Rob Clark wrote: > > > > [...] > > > > > > RT planning and partitioning is not easy task for sure. You might want to > > > > consider using affinities too to get stronger guarantees for some tasks and > > > > prevent cross-talking. > > > > > > There is some cgroup stuff that is pinning SF and some other stuff to > > > the small cores, fwiw.. I think the reasoning is that they shouldn't > > > be doing anything heavy enough to need the big cores. > > > > Ah, so you're on big.LITTLE type of system. I have done some work which enables > > biasing RT tasks towards big cores and control the default boost value if you > > have util_clamp and schedutil enabled. You can use util_clamp in general to > > help with DVFS related response time delays. > > > > I haven't done any work to try our best to pick a small core first but fallback > > to big if there's no other alternative. > > > > It'd be interesting to know how often you end up on a big core if you remove > > the affinity. The RT scheduler picks the first cpu in the lowest priority mask. > > So it should have this bias towards picking smaller cores first if they're > > in the lower priority mask (ie: not running higher priority RT tasks). > > fwiw, the issue I'm looking at is actually at the opposite end of the > spectrum, less demanding apps that let cpus throttle down to low > OPPs.. which stretches out the time taken at each step in the path > towards screen (which seems to improve the odds that we hit priority > inversion scenarios with SCHED_FIFO things stomping on important CFS > things) So you do have the problem of RT task preempting an important CFS task. > > There is a *big* difference in # of cpu cycles per frame between > highest and lowest OPP.. To combat DVFS related delays, you can use util clamp. Hopefully this article helps explain it if you didn't come across it before https://lwn.net/Articles/762043/ You can use sched_setattr() to set SCHED_FLAG_UTIL_CLAMP_MIN for a task. This will guarantee everytime this task is running it'll appear it has at least this utilization value, so schedutil governor (which must be used for this to work) will pick up the right performance point (OPP). The scheduler will try its best to make sure that the task will run on a core that meets the minimum requested performance point (hinted by setting uclamp_min). Thanks -- Qais Yousef _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel