From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757121AbcBCMDP (ORCPT ); Wed, 3 Feb 2016 07:03:15 -0500 Received: from e37.co.us.ibm.com ([32.97.110.158]:45822 "EHLO e37.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756423AbcBCMDL (ORCPT ); Wed, 3 Feb 2016 07:03:11 -0500 X-IBM-Helo: d03dlp01.boulder.ibm.com X-IBM-MailFrom: ego@linux.vnet.ibm.com X-IBM-RcptTo: linux-api@vger.kernel.org;linux-kernel@vger.kernel.org;linux-pm@vger.kernel.org Date: Wed, 3 Feb 2016 17:32:58 +0530 From: Gautham R Shenoy To: Viresh Kumar Cc: Shilpasri G Bhat , linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org, rjw@rjwysocki.net, linux-pm@vger.kernel.org, pc@us.ibm.com, anton@samba.org, ego@linux.vnet.ibm.com, shreyas@linux.vnet.ibm.com, bsingharora@gmail.com, mpe@ellerman.id.au, linux-api@vger.kernel.org Subject: Re: [PATCH v8 6/6] cpufreq: powernv: Add sysfs attributes to show throttle stats Message-ID: <20160203120258.GA32294@in.ibm.com> Reply-To: ego@linux.vnet.ibm.com References: <1454442102-1229-1-git-send-email-shilpa.bhat@linux.vnet.ibm.com> <1454442102-1229-7-git-send-email-shilpa.bhat@linux.vnet.ibm.com> <20160203082700.GZ31828@vireshk> <56B1BD71.2050403@linux.vnet.ibm.com> <20160203090357.GA31828@vireshk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160203090357.GA31828@vireshk> User-Agent: Mutt/1.5.23 (2014-03-12) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16020312-0025-0000-0000-00002103143E Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Viresh, > > What I can suggest is: > - Move this directory inside cpuX/cpufreq/ directory, in a similar way > as to how we create 'stats' directory today. > - You can then get policy->cpu, to get chip->id out of it. > - The only disadvantage here is that the same chip directory will be > replicated in multiple policies, but that makes it more readable. Thinking about it, having a sysfs group attached to a policy kobject looks ok if replication of the same chip information across multiple policies is not objectionable. Regarding the table-format, it breaks the sysfs's one-value-per-file rule. So I would still prefer each throttle reason being a separate file which gives the number of times the chip frequency was throttled due to that reason. We can live without the per-frequency throttle stats listed in the throttle_status. So, would the following be sysfs group structure be acceptable? $ls -1 /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/ unthrottle powercap overtemp supply_fault overcurrent occ_reset turbo_stat sub_turbo_stat -- Thanks and Regards gautham.