On 13/07/17 18:48, Prashanth Prakash wrote: > Add support to expose idle statistics maintained by platform to > userspace via sysfs in addition to other data of interest from > each LPI(Low Power Idle) state. > > LPI described in section 8.4.4 of ACPI spec 6.1 provides different > methods to obtain idle statistics maintained by the platform. These > show a granular view of how each of the LPI state is being used at > different level of hierarchy. sysfs data is exposed at each level in > the hierarchy by creating a directory named 'lpi' at each level and > the LPI state information is presented under it. Below is the > representation of LPI information at one such level in the hierarchy > > .../ACPI00XX: XX/lpi > |-> state0 > | |-> desc > | |-> time > | |-> usage > | |-> latency > | |-> min_residency > | > <<more states>> > > ACPI00XX can be ACPI0007(processor) or ACPI0010(processor container) > > stateX contains information related to a specific LPI state defined > in the LPI ACPI tables. > > Signed-off-by: Prashanth Prakash <pprakash@xxxxxxxxxxxxxx> > --- > v2 > * Add Documentation/ABI/testing/sysfs-acpi-lpi > v1 > * Drop flags, arch_flags and summary_stats field (Sudeep) > * Create sysfs entries after we know that LPI will be used (Sudeep & Rafael) > > Documentation/ABI/testing/sysfs-acpi-lpi | 47 +++++ > drivers/acpi/processor_idle.c | 343 ++++++++++++++++++++++++++++++- > include/acpi/processor.h | 14 ++ > 3 files changed, 402 insertions(+), 2 deletions(-) > create mode 100644 Documentation/ABI/testing/sysfs-acpi-lpi > > diff --git a/Documentation/ABI/testing/sysfs-acpi-lpi b/Documentation/ABI/testing/sysfs-acpi-lpi > new file mode 100644 > index 0000000..5b054a1 > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-acpi-lpi Sorry for the delay, I initial thought having this ABI under testing is fine as I really don't want any *real* user space programs to depend on this for various reasons stated in earlier threads, e.g. h/w auto promotable states, accuracy of the stats, ..etc But from Documentation/ABI/README, I see testing/ This directory documents interfaces that are felt to be stable, as the main development of this interface has been completed. The interface can be changed to add new features, but the current interface will not break by doing this, unless grave errors or security problems are found in them. User space programs can start to rely on these interfaces,... which makes me worry. Since the use for this is purely for debug or optimization purposes, I still prefer simple single file debugfs entry. I still can't digest the fact that reading single file is time consuming as we are not using this interface at runtime IIUC. i.e. statistic are collected and analyzed offline. But if Rafael is fine with this, that's fine. -- Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
