Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1471036imm; Tue, 22 May 2018 04:45:50 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrfrNVh0Cr2T+LrugS5KwCBLugNatjQU9zeqk7jCoVrhBo71LhEdxDSkQDry5MbRAWgcFD3 X-Received: by 2002:a62:d286:: with SMTP id c128-v6mr24034371pfg.240.1526989550249; Tue, 22 May 2018 04:45:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526989550; cv=none; d=google.com; s=arc-20160816; b=uiu93+9NAdjVnnE1yIu7oOVOI0YDAjyKDFLnC+KygNpzXYfenD1ARiTfg+qTcIzLab qyPGpa8LSfExoTA1zKwB+d48izyvg/xaHfVqa9tydMla93iAeiltIXT1WgxNUkMudIDE qwIV/xj8eLgxkKwfTkYKXTF/zDnhmuIkR9rsb9xMOGncllP2qMG+fYMEkoW/2iIhc2Ky z7w/QLYTlEDGTdRrEaGm7gqWlqHe5uuxA58QQb/L4Kca0k0YlgReSHSwGK7TBQFEia3J gSmIPsKmMFeBk1FSKxs3Zpn3YZl4ZEW5Vnrf7mz/CkeTbvvbvkFQ8f666AbigsWC17gQ pL7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=r75hpFZZ4K6sC5yC5wA7RVMDzuXLFau7NENtKoypKdc=; b=QReEpj/EiPV447lkKLxDlRzNaFAL6L0Km+dljanIXKhP84XFzmsxnAGVDdcAKJH+zH YG3rwXwSdPm8um1GNkX+EiLk03Je5myg51XX16kE9GecKxp51lR2e7chs/QaSFZK5X4Y H2RUjouIUv2aGM7w1i4VTbfB8TkJy8qNMvvQrrabHc4afCHiRkkn1UWqCaLlcM3JSrz1 Frv107ti1dfmsjMONDlwH+H5LzFN/5j/2fruHL2L6Ka/rhBqz+xcucSZkcb1WUkQ0Re7 /+gP1T/p74G1UjNmzbOWqVEknzXEceovqoI3DSQMZBGvPuN82Ydmm2bFd4XWaedN5RUV HBxQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=e5DmEItU; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c23-v6si16476310pli.540.2018.05.22.04.45.33; Tue, 22 May 2018 04:45:50 -0700 (PDT) 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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=e5DmEItU; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751737AbeEVLnv (ORCPT + 99 others); Tue, 22 May 2018 07:43:51 -0400 Received: from mail-ot0-f193.google.com ([74.125.82.193]:43960 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751778AbeEVLmG (ORCPT ); Tue, 22 May 2018 07:42:06 -0400 Received: by mail-ot0-f193.google.com with SMTP id y10-v6so20541888otg.10; Tue, 22 May 2018 04:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=r75hpFZZ4K6sC5yC5wA7RVMDzuXLFau7NENtKoypKdc=; b=e5DmEItUS8OQRMqshe3LuQxXoh62il9xBJBpb0qpvxkxFBFANpjRrjD0FXjp8D+NDO 4RC9bmx7x3v03IE/oZQ6MCNcy0ETPWFJIufAPBPgZpKYjUdMIAzAOzgCo+yfU8TyD9P0 Hj7OulCXQedzkDCQEdNX1PrZoMS2NPUu8FiAI7tfuJInz4j2XbkI1A3IDiyfjNXQGSsn D5D97uoTZWULhx4Qk8lc2tp5hEkR25v4zJFOUytvfTB3H+wE7juxsyLWa3sjuVnLVphA agym24oJrSa8TD0sq7t88+GIvQk79ghHsLxrmraoBjQdE17sjxUTkDmTpOkdATWiAfPK xpKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=r75hpFZZ4K6sC5yC5wA7RVMDzuXLFau7NENtKoypKdc=; b=sF2ODeawYykjKQMVxB+xbXFkuLhX0uaPIGLLuf4F9Bub6NHGjozNry6gW1+06Fm7Or XYOAt6RujZtAtk606FKEmFfWiNFdVM91MLQSkcBVyJFEFvmzacOB6auU4FcOW31QcGpR N8vQpjqcGeSACTBw1v7Ad75e7cdHbe8wcrWlxbDaPLPzgrco1VPwlGL0ynIPKRcsk2uc O7hYu6F59KP6UjHXt4QxY2gFBDHh5zq5JgtQ5LqJNDbFNpZCC3AEOABkxAm9lIddb0dc aR7zG5X3J7fCHTPpSGk2fN2PQu67vihrKk+H+XYjkMpAiVagQVsyx5oe/QdcNkfPcfwQ eRqA== X-Gm-Message-State: ALKqPwcjXfYBe4GOjtFzRsVddwB0VCBMui8cM54z+Y7FTrqAIKNMs16p nd7wNsix7+wvcGLl4ATTSz3xiVX28Rla03pL3fU= X-Received: by 2002:a9d:3e07:: with SMTP id a7-v6mr15170840otd.150.1526989325601; Tue, 22 May 2018 04:42:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1468:0:0:0:0:0 with HTTP; Tue, 22 May 2018 04:42:05 -0700 (PDT) In-Reply-To: <20180522113844.5rz3skjeck57arft@vireshk-i7> References: <20180518185501.173552-1-joel@joelfernandes.org> <4393838.cQWhzXzUcj@aspire.rjw.lan> <20180522105429.yn2omuz63oa2w3ez@vireshk-i7> <6163159.YL3rkaEOau@aspire.rjw.lan> <20180522113844.5rz3skjeck57arft@vireshk-i7> From: "Rafael J. Wysocki" Date: Tue, 22 May 2018 13:42:05 +0200 X-Google-Sender-Auth: KmEsvl0fcCNU3rdcFV0NuFPU_1U Message-ID: Subject: Re: [PATCH v2] schedutil: Allow cpufreq requests to be made even when kthread kicked To: Viresh Kumar Cc: "Rafael J. Wysocki" , "Joel Fernandes (Google.)" , Linux Kernel Mailing List , "Joel Fernandes (Google)" , "Rafael J . Wysocki" , Peter Zijlstra , Ingo Molnar , Patrick Bellasi , Juri Lelli , Luca Abeni , Todd Kjos , Claudio Scordino , kernel-team@android.com, Linux PM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 22, 2018 at 1:38 PM, Viresh Kumar wrote: > On 22-05-18, 13:31, Rafael J. Wysocki wrote: >> So below is my (compiled-only) version of the $subject patch, obviously based >> on the Joel's work. >> >> Roughly, what it does is to move the fast_switch_enabled path entirely to >> sugov_update_single() and take the spinlock around sugov_update_commit() >> in the one-CPU case too. >> >> --- >> kernel/sched/cpufreq_schedutil.c | 57 ++++++++++++++++++++++++++------------- >> 1 file changed, 38 insertions(+), 19 deletions(-) >> >> Index: linux-pm/kernel/sched/cpufreq_schedutil.c >> =================================================================== >> --- linux-pm.orig/kernel/sched/cpufreq_schedutil.c >> +++ linux-pm/kernel/sched/cpufreq_schedutil.c >> @@ -92,9 +92,6 @@ static bool sugov_should_update_freq(str >> !cpufreq_can_do_remote_dvfs(sg_policy->policy)) >> return false; >> >> - if (sg_policy->work_in_progress) >> - return false; >> - >> if (unlikely(sg_policy->need_freq_update)) >> return true; >> >> @@ -103,25 +100,25 @@ static bool sugov_should_update_freq(str >> return delta_ns >= sg_policy->freq_update_delay_ns; >> } >> >> -static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time, >> - unsigned int next_freq) >> +static bool sugov_update_next_freq(struct sugov_policy *sg_policy, u64 time, >> + unsigned int next_freq) >> { >> - struct cpufreq_policy *policy = sg_policy->policy; >> - >> if (sg_policy->next_freq == next_freq) >> - return; >> + return false; >> >> sg_policy->next_freq = next_freq; >> sg_policy->last_freq_update_time = time; >> >> - if (policy->fast_switch_enabled) { >> - next_freq = cpufreq_driver_fast_switch(policy, next_freq); >> - if (!next_freq) >> - return; >> + return true; >> +} >> >> - policy->cur = next_freq; >> - trace_cpu_frequency(next_freq, smp_processor_id()); >> - } else { >> +static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time, >> + unsigned int next_freq) >> +{ >> + if (!sugov_update_next_freq(sg_policy, time, next_freq)) >> + return; >> + >> + if (!sg_policy->work_in_progress) { >> sg_policy->work_in_progress = true; >> irq_work_queue(&sg_policy->irq_work); >> } >> @@ -277,6 +274,7 @@ static void sugov_update_single(struct u >> { >> struct sugov_cpu *sg_cpu = container_of(hook, struct sugov_cpu, update_util); >> struct sugov_policy *sg_policy = sg_cpu->sg_policy; >> + struct cpufreq_policy *policy = sg_policy->policy; >> unsigned long util, max; >> unsigned int next_f; >> bool busy; >> @@ -307,7 +305,23 @@ static void sugov_update_single(struct u >> sg_policy->cached_raw_freq = 0; >> } >> >> - sugov_update_commit(sg_policy, time, next_f); >> + if (policy->fast_switch_enabled) { > > Why do you assume that fast switch isn't possible in shared policy > cases ? It infact is already enabled for few drivers. OK, so the fast_switch thing needs to be left outside of the spinlock in the single case only. Fair enough.