Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752836AbdGGF0j (ORCPT ); Fri, 7 Jul 2017 01:26:39 -0400 Received: from mail-oi0-f49.google.com ([209.85.218.49]:36252 "EHLO mail-oi0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750895AbdGGF0i (ORCPT ); Fri, 7 Jul 2017 01:26:38 -0400 MIME-Version: 1.0 In-Reply-To: <20170705134126.GD2659@e110439-lin> References: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> <1499189651-18797-4-git-send-email-patrick.bellasi@arm.com> <20170705060136.GO3532@vireshk-i7> <20170705134126.GD2659@e110439-lin> From: Joel Fernandes Date: Thu, 6 Jul 2017 22:26:36 -0700 Message-ID: Subject: Re: [PATCH v2 3/6] cpufreq: schedutil: ensure max frequency while running RT/DL tasks To: Patrick Bellasi Cc: Viresh Kumar , LKML , Linux PM , Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Vincent Guittot , Juri Lelli , Andres Oportus , Todd Kjos , Morten Rasmussen , Dietmar Eggemann , Steve Muckle , Brendan Jackman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1307 Lines: 36 Hi, On Wed, Jul 5, 2017 at 6:41 AM, Patrick Bellasi wrote: [..] > >> But what about clearing the sched-class's flag from .pick_next_task() callback >> when they return NULL ? >> >> What about something like this instead (completely untested), with which we >> don't need the 2/3 patch as well: > > Just had a fast check but I think something like that can work. > We had an internal discussion with Brendan (in CC now) which had a > similar proposal. > > Main counter arguments for me was: > 1. we wanna to reduce the pollution of scheduling classes code with > schedutil specific code, unless strictly necessary > 2. we never had a "clear bit" semantics for flags updates > > Thus this proposal seemed to me less of a discontinuity wrt the > current interface. However, something similar to what you propose > below should also work. Let's collect some more feedback... > I was going to say something similar. I feel its much cleaner if the scheduler clears the flags that it set, thus taking "ownership" of the flag. I feel that will avoid complication like this where the governor has to peek into what's currently running and such (and also help with the suggestion I made for patch 2/3. Maybe the interface needs an extension for "clear flag" semantics? thanks, -Joel