Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932215AbdGKFTj (ORCPT ); Tue, 11 Jul 2017 01:19:39 -0400 Received: from mail-oi0-f48.google.com ([209.85.218.48]:34255 "EHLO mail-oi0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932111AbdGKFTh (ORCPT ); Tue, 11 Jul 2017 01:19:37 -0400 MIME-Version: 1.0 In-Reply-To: References: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> <1499189651-18797-5-git-send-email-patrick.bellasi@arm.com> From: Joel Fernandes Date: Mon, 10 Jul 2017 22:19:35 -0700 Message-ID: Subject: Re: [PATCH v2 4/6] cpufreq: schedutil: update CFS util only if used To: Vikram Mulukutla Cc: Patrick Bellasi , LKML , Linux PM , Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Juri Lelli , Andres Oportus , Todd Kjos , Morten Rasmussen , Dietmar Eggemann , linux-kernel-owner@vger.kernel.org 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: 1586 Lines: 42 On Mon, Jul 10, 2017 at 10:49 AM, Vikram Mulukutla wrote: [..] > >>> Given that the utilization update hooks are called with the per-cpu rq >>> lock >>> held (for all classes), I don't think PELT utilization can change >>> throughout >>> the lifetime of the cpufreq_update_{util,this_cpu} call? Even with >>> Viresh's >>> remote cpu callback series we'd still have to hold the rq lock across >>> cpufreq_update_util.. what can change today is 'max' >>> (arch_scale_cpu_capacity) when a cpufreq policy is shared, so the patch >>> is >>> still needed for that reason I think? >>> >> >> I didn't follow, Could you elaborate more why you think the patch >> helps with the case where max changes while the per-cpu rq lock held? >> > > So going by Patrick's commit text, the concern was a TOC/TOU > problem, but since we agree that CFS utilization can't change > within an rq-locked critical section, the only thing that can > change is 'max'. So you might be the 8th cpu in line waiting > for the sg-policy lock, and after you get the lock, the max may > be outdated. > > But come to think of it max changes should be triggering schedutil > updates and those shouldn't be rate-throttled, so maybe we don't > need this at all? It's still somewhat future-proof in case there > is some stat that we read in sugov_get_util that can be updated > asynchronously. However we can put it in when we need it... It looks like Juri's patch [1] to split signals already cleaned it up so we should be all set ;-) Thanks, -Joel [1] https://patchwork.kernel.org/patch/9826201/