From mboxrd@z Thu Jan 1 00:00:00 1970 From: Viresh Kumar Subject: Re: [PATCH V2 06/10] cpufreq: governor: Keep single copy of information common to policy->cpus Date: Mon, 30 Nov 2015 16:33:27 +0530 Message-ID: <20151130110327.GC4899@ubuntu> References: <1448625400.3689.103.camel@pengutronix.de> <20151130051915.GH3373@ubuntu> <1448879672.8275.15.camel@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-pa0-f52.google.com ([209.85.220.52]:36481 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751018AbbK3LDb (ORCPT ); Mon, 30 Nov 2015 06:03:31 -0500 Received: by pacdm15 with SMTP id dm15so181971420pac.3 for ; Mon, 30 Nov 2015 03:03:30 -0800 (PST) Content-Disposition: inline In-Reply-To: <1448879672.8275.15.camel@pengutronix.de> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Lucas Stach Cc: Rafael Wysocki , Preeti U Murthy , ke.wang@spreadtrum.com, linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, ego@linux.vnet.ibm.com, paulus@samba.org, shilpa.bhat@linux.vnet.ibm.com, prarit@redhat.com, robert.schoene@tu-dresden.de, skannan@codeaurora.org On 30-11-15, 11:34, Lucas Stach wrote: > The timer_mutex is one of the top contended locks already on a quad core > system. My new series (un-committed) should fix that to some level hopefully: http://marc.info/?l=linux-pm&m=144612165211091&w=2 > That really doesn't look right, as the timer is quite low > frequency. It's causing excessive wake ups, as all 4 CPUs wake up to > handle the WQ, 3 of them directly go back to sleep waiting for the mutex > to be released, then same thing happens for CPUs-1 until we rippled down > to a single CPU. There is a reason why we need to do this on all CPUs today. The timers are deferrable by nature, as we shouldn't wake up a CPU to change it frequency. Now group of CPUs that change their DVFS state together, or that change their voltage/clock rails are part of the same cpufreq-policy. We need to take load of all the CPUs, that are part of the policy, while update the frequency of the group. If we queue the timer on any one CPU, then that CPU can go into idle and the deferred timer will not fire. But the other CPUs of the policy can still be active and the frequency of the group wouldn't change with load. Hope that answers the query related to timers on all CPUs. > I would say it's still worth fixing. Perhaps by not waking all the > workqueues at the same time, but spreading the wake times out over a > jiffy. Maybe. -- viresh