From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755240AbbJ1GJZ (ORCPT ); Wed, 28 Oct 2015 02:09:25 -0400 Received: from v094114.home.net.pl ([79.96.170.134]:64464 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753192AbbJ1GJX (ORCPT ); Wed, 28 Oct 2015 02:09:23 -0400 From: "Rafael J. Wysocki" To: Viresh Kumar Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, open list Subject: Re: [PATCH V3 3/5] cpufreq: ondemand: queue work for policy->cpus together Date: Wed, 28 Oct 2015 07:38:20 +0100 Message-ID: <1864040.ba6Ezq0vlE@vostro.rjw.lan> User-Agent: KMail/4.11.5 (Linux/4.1.0-rc5+; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, October 13, 2015 01:39:03 PM Viresh Kumar wrote: > Currently update_sampling_rate() runs over each online CPU and > cancels/queues work on it. Its very inefficient for the case where a > single policy manages multiple CPUs, as they can be processed together. In the case of one policy object shared between multiple CPUs, I'm wondering why we don't use a single delayed work function for all of them in the first place. That would address the problem at the source instead of dealing with the symptoms. > Also drop the unnecessary cancel_delayed_work_sync() as we are doing a > mod_delayed_work_on() in gov_queue_work(), which will take care of > pending works for us. I'd prefer a separate patch for that if poss. Thanks, Rafael