Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3095053imm; Thu, 17 May 2018 03:20:57 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqa1RiV9Qn/VGRP0vFlR3xI11n5IgwU6sBrm8Acg8jhfcTEe9jyIt1xtZ4VAAo3Ddp/6fnW X-Received: by 2002:a65:49c3:: with SMTP id t3-v6mr3606294pgs.65.1526552457475; Thu, 17 May 2018 03:20:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526552457; cv=none; d=google.com; s=arc-20160816; b=U3F7P/dnPdL2JwSi3ykWfdGTfq67QWAzMOcc6ZBL/Q48xN0S2a81cNoNyB+eR/x3US anvdYgcLM3R1oM38uiD1NtM0Vk99ZsbGsrIipU937fMkxshd2tHiMvhoS7jurhv2q3A/ izW4AH3wQv5VSUy01aA7rEuz52kgOcViCN0JpJBs8UE5aOWyQtI3Mr641HeAJWEzZpOI b8mhxVls6d/a/99liRR9djgbXXryGpmYWFgVIGCRVwXdTycsNpZ9LpTEUMb24lyzCg+j J+jZpfh3gY/PVRz8FYSl5T858JqFcZ33yKXeHrOCIFrpj620FH1fr9Oly4847V5C6cKk Fcpw== 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:dkim-signature:arc-authentication-results; bh=gRB08O0UTV2u0hLKIfVKJD9o79qZ5qnCRCQxhev1yPw=; b=I0wG1XdOLuKWWjGVg51mfrJ2yPzAyHKcXKUnR2KCFZdYFvxdpcdTkdu307dqvdv1Qu WBn+Df63JTl8y5XPbi2DrCDD0bqcTzJ1FlRgBmqdMZQ4cmNTduWiBEzyFApZFF+BVYqb INOCe6ddw3DVu94BQFSTaUAHFYeyEoVF22zAekab87Cu0LkMwB93lEWxTp5T1CjwQpqh oAmLu0fHS9wpajibPU/gep2UbkRhO3lxpttRioDSPvgpTALIq/9I4L1z0K7f3bb0SQPm qaBSy3RZfAFKFu9rNF73RqUigtE+qs6rVLXxwAofbLFapmnwk2s5iFbtfLwP3+gAFXpf rE7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=iZY3Hser; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y65-v6si4975354pfy.230.2018.05.17.03.20.42; Thu, 17 May 2018 03:20:57 -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=pass header.i=@linaro.org header.s=google header.b=iZY3Hser; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751644AbeEQKUa (ORCPT + 99 others); Thu, 17 May 2018 06:20:30 -0400 Received: from mail-pg0-f68.google.com ([74.125.83.68]:45923 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751280AbeEQKU2 (ORCPT ); Thu, 17 May 2018 06:20:28 -0400 Received: by mail-pg0-f68.google.com with SMTP id w3-v6so1620039pgv.12 for ; Thu, 17 May 2018 03:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=gRB08O0UTV2u0hLKIfVKJD9o79qZ5qnCRCQxhev1yPw=; b=iZY3HserU1CaDiDvr4GTanHSO2b6/UQi/D3D9g8+H5g6AshhrUfz2kCm0QZDQmyTPz EwK8EshnyZywMDhpYnLW7G6wc/6WH8AY94DKyesp4+XMtvjknokXtk2p3kduYQlLCl0E 2TVN71tNP+x/pirsYvBqISUvhaVziwQe34oI0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=gRB08O0UTV2u0hLKIfVKJD9o79qZ5qnCRCQxhev1yPw=; b=G8Dbs1+LwHo0RYCsVdod3gXg9aFVR2usSFUNxR1ia9aFNd/pYb1L8cHAHOvV6B57Ay 7Y1u2RzJjlPxBIyNqSYmMUFCXSARw8ZS0m8oVhdC0cp02Ibg3YEGpPh0WFrePIOdcRDR r9y31iYm2Q126Ssj6Kbx1BnptDYBJOG+eiHTN4x9Koj9kURfRUNPczbOKVpfPv5njmY2 n4qZYOM4dQTUrv/ERT/x4s8dsmpRDOqj6tF1deTbwHGT3I7wzkHmPfAlP8Oh4ARf5/VP NRuSksI7AImmDD6Tw1HzrUB8YY8bU5ERy3uS9CrXzO7nwRjbQnRaMr18b0Fr0zH/0iu8 fYhA== X-Gm-Message-State: ALKqPwcBjeTv2S19UXuvp6uDZu9/DQi/fEPmYjGZudjWbUnlh4IMEB1H LXegqMNCSIjlgoavu5wGefh0A/KyoaE= X-Received: by 2002:a63:5f11:: with SMTP id t17-v6mr3484517pgb.94.1526552427907; Thu, 17 May 2018 03:20:27 -0700 (PDT) Received: from localhost ([122.167.163.112]) by smtp.gmail.com with ESMTPSA id a11-v6sm6536907pgn.64.2018.05.17.03.20.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 May 2018 03:20:27 -0700 (PDT) Date: Thu, 17 May 2018 15:50:24 +0530 From: Viresh Kumar To: Juri Lelli Cc: "Joel Fernandes (Google)" , linux-kernel@vger.kernel.org, "Rafael J . Wysocki" , Peter Zijlstra , Ingo Molnar , Patrick Bellasi , Luca Abeni , Joel Fernandes , linux-pm@vger.kernel.org Subject: Re: [PATCH RFC] schedutil: Allow cpufreq requests to be made even when kthread kicked Message-ID: <20180517102024.s3dxo4uepujh5f65@vireshk-i7> References: <20180516224518.109891-1-joel@joelfernandes.org> <20180517070026.GA22493@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180517070026.GA22493@localhost.localdomain> User-Agent: NeoMutt/20180323-120-3dd1ac Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17-05-18, 09:00, Juri Lelli wrote: > Hi Joel, > > On 16/05/18 15:45, Joel Fernandes (Google) wrote: > > [...] > > > @@ -382,13 +391,24 @@ sugov_update_shared(struct update_util_data *hook, u64 time, unsigned int flags) > > static void sugov_work(struct kthread_work *work) > > { > > struct sugov_policy *sg_policy = container_of(work, struct sugov_policy, work); > > + unsigned int freq; > > + unsigned long flags; > > + > > + /* > > + * Hold sg_policy->update_lock shortly to handle the case where: > > + * incase sg_policy->next_freq is read here, and then updated by > > + * sugov_update_shared just before work_in_progress is set to false > > + * here, we may miss queueing the new update. > > + */ > > + raw_spin_lock_irqsave(&sg_policy->update_lock, flags); > > + freq = sg_policy->next_freq; > > + sg_policy->work_in_progress = false; > > + raw_spin_unlock_irqrestore(&sg_policy->update_lock, flags); > > OK, we queue the new request up, but still we need to let this kthread > activation complete and then wake it up again to service the request > already queued, right? Wasn't what Claudio proposed (service back to > back requests all in the same kthread activation) better from an > overhead pow? We would need more locking stuff in the work handler in that case and I think there maybe a chance of missing the request in that solution if the request happens right at the end of when sugov_work returns. -- viresh