Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755939AbbEUOet (ORCPT ); Thu, 21 May 2015 10:34:49 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:35059 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754097AbbEUOeq (ORCPT ); Thu, 21 May 2015 10:34:46 -0400 Message-ID: <555DED03.9070002@linaro.org> Date: Thu, 21 May 2015 16:34:43 +0200 From: Daniel Lezcano User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ruchi Kandoi , "Rafael J. Wysocki" , Viresh Kumar , Ingo Molnar , Peter Zijlstra , Andrew Morton , Oleg Nesterov , "Kirill A. Shutemov" , Vladimir Davydov , Heinrich Schuchardt , Thomas Gleixner , Kees Cook , Konstantin Khlebnikov , Davidlohr Bueso , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/2] Adds cpu power accounting per-pid basis. References: <1431648770-7404-1-git-send-email-kandoiruchi@google.com> In-Reply-To: <1431648770-7404-1-git-send-email-kandoiruchi@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3093 Lines: 73 Hi Ruchi, On 05/15/2015 02:12 AM, Ruchi Kandoi wrote: > These patches add a mechanism which will accurately caculate the CPU power > used by all the processes in the system. In order to account for the power > used by all the processes a data field "cpu_power" has been added in the > task_struct. The term 'energy' makes more sense than 'power'. > This field adds power for both the system as well as user > time. cpu_power contains the total amount of charge(in uAmsec units) used Why not use the Joules unit ? > by the process. This model takes into account the frequency at which the > process was running(i.e higher power for processes running at higher > frequencies). It requires the cpufreq_stats module to be initialized with > the current numbers for each of the CPU core at each frequency. This will > be initialized during init time. The energy task accounting is an interesting feature in my opinion. But your patchset does not deal with the power management hardware complexity. If we reduce the scope of the task energy accounting to the cpu, we are facing several issues: * A cpu may be supposed to run at a specific OPP but it could share a clock line with another cpu which is in a higher frequency. So the frequency is actually at a higher rate than what is assumed * The firmware may override the cpufreq decisions * A process may be idle but its behavior forces the cpuidle governor to choose shallow states (that won't occur without the process). For example, the process is using very short timers, does a small processing and then go to sleep again waiting for the next timer expiration. The result will be a process having a low energy consumption but actually because of these timers, it will prevent the cpu to enter deep idle state Beside that, the process may be soliciting a subsystem (another process or hardware) which consumes a lot of energy. That won't be accounted even if the process is responsible of this extra consumption. And the last point is: how do you expect to have the energy numbers as nobody is willing to share them for their platform ? > Ruchi Kandoi (2): > cpufreq_stats: Adds sysfs file > /sys/devices/system/cpu/cpufreq/current_in_state > sched: cpufreq: Adds a field cpu_power in the task_struct > > drivers/cpufreq/cpufreq_stats.c | 191 +++++++++++++++++++++++++++++++++++++++- > include/linux/cpufreq.h | 8 ++ > include/linux/sched.h | 2 + > kernel/fork.c | 1 + > kernel/sched/cputime.c | 7 ++ > 5 files changed, 207 insertions(+), 2 deletions(-) -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/