From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
To: "Valentin, Eduardo" <eduardo.valentin@ti.com>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
ShuoX Liu <shuox.liu@intel.com>,
"Brown, Len" <len.brown@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-pm@lists.linux-foundation.org"
<linux-pm@lists.linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>,
greg@kroah.com
Subject: Re: [linux-pm] [PATCH V3] cpuidle: Add a sysfs entry to disable specific C state for debug purpose.
Date: Tue, 06 Mar 2012 09:54:45 +0800 [thread overview]
Message-ID: <1330998885.1916.89.camel@ymzhang> (raw)
In-Reply-To: <CAGF5oy_BUytjeDa8Oc62pRabaEqwqKCFuVJuzLd-XNZg34ne2w@mail.gmail.com>
On Mon, 2012-03-05 at 14:20 +0200, Valentin, Eduardo wrote:
> Hello,
>
>
> On Mon, Mar 5, 2012 at 12:18 PM, Henrique de Moraes Holschuh
> <hmh@hmh.eng.br> wrote:
> > On Mon, 05 Mar 2012, ShuoX Liu wrote:
> >> @@ -45,6 +46,7 @@ total 0
> >> /sys/devices/system/cpu/cpu0/cpuidle/state1:
> >> total 0
> >> -r--r--r-- 1 root root 4096 Feb 8 10:42 desc
> >> +-rw-r--r-- 1 root root 4096 Feb 8 10:42 disable
> >> -r--r--r-- 1 root root 4096 Feb 8 10:42 latency
> >> -r--r--r-- 1 root root 4096 Feb 8 10:42 name
> >> -r--r--r-- 1 root root 4096 Feb 8 10:42 power
> >
> > ...
> >
> >> diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
> >> index 3fe41fe..1eae29a 100644
> >> --- a/drivers/cpuidle/sysfs.c
> >> +++ b/drivers/cpuidle/sysfs.c
> >> @@ -222,6 +222,9 @@ struct cpuidle_state_attr {
> >> #define define_one_state_ro(_name, show) \
> >> static struct cpuidle_state_attr attr_##_name = __ATTR(_name, 0444,
> >> show, NULL)
> >>
> >> +#define define_one_state_rw(_name, show, store) \
> >> +static struct cpuidle_state_attr attr_##_name = __ATTR(_name, 0644,
> >> show, store)
> >> +
> >> #define define_show_state_function(_name) \
> >> static ssize_t show_state_##_name(struct cpuidle_state *state, \
> >> struct cpuidle_state_usage *state_usage, char *buf) \
> >> @@ -229,6 +232,19 @@ static ssize_t show_state_##_name(struct
> >> cpuidle_state *state, \
> >> return sprintf(buf, "%u\n", state->_name);\
> >> }
> >>
> >> +#define define_store_state_function(_name) \
> >> +static ssize_t store_state_##_name(struct cpuidle_state *state, \
> >> + const char *buf, size_t size) \
> >> +{ \
> >> + int value; \
> >> + sscanf(buf, "%d", &value); \
> >> + if (value) \
> >> + state->disable = 1; \
> >> + else \
> >> + state->disable = 0; \
> >> + return size; \
> >> +}
> >
> > Isn't this missing a check for capabilities? Disabling cpuidle states is
> > not something random Joe (and IMHO that does mean random capability-
> > restricted Joe root) should be doing...
> >
> > Also, maybe it would be best to use one of the lib helpers to parse that
> > value, so that it will be less annoying to userspace (trim blanks, complain
> > if there is trailing junk after trimming, etc)?
>
> I may be jumping the thread in the middle but, if it is for debug
> purposes, as states the subject, shouldn't this entry go to debugfs
> instead of sysfs? I know cpuidle has all the infrastructure there to
> simply add another sysfs entry, but if the intent is to create a debug
> capability, then I'd say it fits under debugfs instead. Adding Greg
> KH here, as I suppose he may have strong opinion on using sysfs for
> debugging.
Thanks for the comments.
IMHO, all entries under cpuidle directory are for debug purpose. End users
shouldn't care about them. If we rewrite codes around all the entries, I strongly
agree that we need move them to debugfs.
Here, we just add a new entry under same directory. If we create it under debugfs,
we need create the similar directory tree, which is a duplicate effort. In addition,
users might be confused that why we separate the entries under sysfs and debugfs.
>
> Of course, if you are targeting user space control over C states on
> production systems, then it's a different thing then.
Although we say it's mostly for debug purpose used by developers, end users could
use it on production systems. For example, they might get a new machine and installed
an official Linux OS on it. They could do some tuning without recompiling the kernel
when recompiling is impossible.
next prev parent reply other threads:[~2012-03-06 1:54 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <C6CB66606345BC4B80CBE69D22ABFBB1021C7F@SHSMSX101.ccr.corp.intel.com>
[not found] ` <1330647453.1916.7.camel@ymzhang>
[not found] ` <20120302142303.648285a7.akpm@linux-foundation.org>
[not found] ` <C6CB66606345BC4B80CBE69D22ABFBB10220E1@SHSMSX101.ccr.corp.intel.com>
2012-03-05 6:16 ` Subject: [PATCH] cpuidle: Add a sysfs entry to disable specific C state for debug purpose Deepthi Dharwar
2012-03-05 7:09 ` [PATCH V3] " ShuoX Liu
2012-03-05 10:18 ` Henrique de Moraes Holschuh
2012-03-05 12:20 ` Valentin, Eduardo
2012-03-06 1:54 ` Yanmin Zhang [this message]
2012-03-06 5:22 ` [linux-pm] " Greg KH
2012-03-06 5:51 ` Yanmin Zhang
2012-03-06 14:39 ` Greg KH
[not found] ` <1331082051.1916.124.camel@ymzhang>
[not found] ` <20120308180106.GD26516@kroah.com>
2012-03-12 9:19 ` [PATCH 1/3] cpuidle: Move cpuidle sysfs entry of each cpu to debugfs ShuoX Liu
2012-03-12 9:21 ` [PATCH 2/3] cpuidle: Add a debugfs entry to disable specific C state for debug purpose ShuoX Liu
2012-03-12 20:46 ` Matthew Garrett
2012-03-12 9:23 ` [PATCH 3/3] cpupower: Update the cpupower tool for new debugfs entries of cpuidle ShuoX Liu
2012-03-12 17:22 ` [PATCH 1/3] cpuidle: Move cpuidle sysfs entry of each cpu to debugfs Greg KH
2012-03-13 2:07 ` ShuoX Liu
2012-03-12 18:11 ` [PATCH V3] cpuidle: Add a sysfs entry to disable specific C state for debug purpose Mark Brown
2012-03-12 19:29 ` [linux-pm] " Greg KH
2012-03-13 1:36 ` Yanmin Zhang
2012-03-13 19:29 ` Greg KH
2012-03-14 0:55 ` Yanmin Zhang
2012-03-14 2:46 ` Greg KH
2012-03-14 3:24 ` [linux-pm] [PATCH v4] " ShuoX Liu
2012-03-16 0:23 ` Yanmin Zhang
2012-03-16 21:33 ` Andrew Morton
2012-03-18 13:38 ` Henrique de Moraes Holschuh
2012-03-16 22:23 ` Andrew Morton
2012-03-06 1:04 ` [PATCH V3] " Yanmin Zhang
2012-03-13 0:42 ` Henrique de Moraes Holschuh
2012-03-13 1:18 ` Yanmin Zhang
2012-03-13 20:49 ` Henrique de Moraes Holschuh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1330998885.1916.89.camel@ymzhang \
--to=yanmin_zhang@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=eduardo.valentin@ti.com \
--cc=greg@kroah.com \
--cc=hmh@hmh.eng.br \
--cc=hpa@zytor.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=mingo@elte.hu \
--cc=shuox.liu@intel.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).