Received: by 10.223.176.5 with SMTP id f5csp991492wra; Tue, 6 Feb 2018 10:39:14 -0800 (PST) X-Google-Smtp-Source: AH8x226d1B7wiS0a22wC9Xt+n/hp+Nuu3PdxmMJOEoRzsJ6H+I8DvD1j+BLo/vRb+0dnnKDZ4FxD X-Received: by 10.99.181.72 with SMTP id u8mr2692758pgo.205.1517942354457; Tue, 06 Feb 2018 10:39:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517942354; cv=none; d=google.com; s=arc-20160816; b=xS4Yx7D4Vpxa+yVEJ+tBU/mgAe+6VqA437Ets6ZDmcwWM8HC3RyW8K5YNbV+AVT0Mr 1cmE3edlFHAiYuW7MJoC51fPvUeskY9kYl/hQrnMMKDYkGPlIl5lUrPVkkglWpeEO0Gj UQ6Wl89kwWp3BuFcFYOytMSsN4masTBKCwU1cOIBlLfgGdsCdAHO2Ec9aya3DVAlhvBv 50hq7ZPi3nQ3tuFrYUg3MFKmzK6OXudnqm7WKSusTXLsFBBQdp3kj0Ok2MqgCFASnVLM bNocdqstk/NDqHcxvq8tAhkJOKLHAhX+USBlRJ1LF6NclS1Gjbm+uLsn6YQBRs7vNuyc agDw== 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:arc-authentication-results; bh=WlWkVVfqj17S3bc1ewQoUdQmYQunrnLzuNSW33pp9p0=; b=cwp3JxGcn2t/FG9xIMs3LVa/2SeQ2h36U+tbSNgWbYFPVIarhCSvxAwFzBIsyjkKQZ 1SB0GJkcgLu6Q2mCdUsR/+PRq1wW/822gB++aNAPNWGgtkAprRkp4nLntGbE5IbHwIYB BpkzjAF+bypB7o/UJTZCjdCfkZxNu42U82lnHkeh0R/SrruQFrLG0FpAZhj4QIOtZTNt eocJYPbT9MalFkVMpd9awh8HuY3mCab8AMqo3/i58FrZv0YFH3DtYC/255497lTh1JVC OizgSOq6GycB9YYUbci+QyjTCk/M61unuJXKxWClKGu21UFPyn6k6CmBzV3i/osGYSq0 mEHQ== 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 o9si1199587pfi.319.2018.02.06.10.39.00; Tue, 06 Feb 2018 10:39:14 -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 S1753260AbeBFSgf (ORCPT + 99 others); Tue, 6 Feb 2018 13:36:35 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:42004 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753026AbeBFSg3 (ORCPT ); Tue, 6 Feb 2018 13:36:29 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BC6ED80D; Tue, 6 Feb 2018 10:36:28 -0800 (PST) Received: from e110439-lin (e110439-lin.cambridge.arm.com [10.1.210.68]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 854573F25C; Tue, 6 Feb 2018 10:36:26 -0800 (PST) Date: Tue, 6 Feb 2018 18:36:24 +0000 From: Patrick Bellasi To: Claudio Scordino Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes Subject: Re: [PATCH v3 0/6] cpufreq: schedutil: fixes for flags updates Message-ID: <20180206183623.GH5739@e110439-lin> References: <20171130114723.29210-1-patrick.bellasi@arm.com> <20171220153029.dqrtjbyowhqdl56r@hirez.programming.kicks-ass.net> <20180206154319.GF5739@e110439-lin> <68afaf84-893e-6770-b9f1-619cd2b6dc9c@evidence.eu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68afaf84-893e-6770-b9f1-619cd2b6dc9c@evidence.eu.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06-Feb 19:14, Claudio Scordino wrote: > Hi Patrick, > >At first glance, your proposal below makes to make sense. > > > >However, I'm wondering if we cannot get it working using > >rq->dl's provided information instead of flags? > > Yes, we can use the value of rq->dl to check if there has been an increase of the deadline utilization. > Even if schedutil might have been triggered by a different scheduling class, the effect should be almost the same. > > Below a potential patch. I've kept all frequency update decisions in a single point (i.e. sugov_should_update_freq). > Not yet tested (waiting for further comments). I have a todo list entry to backport/test Peter's series on Android... will add this patch too. Thanks. -- #include Patrick Bellasi