Hi Sudeep, On 7/31/2017 10:25 AM, Sudeep Holla wrote: > 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 <sorry for repeating this part> These fields are optional, so if there is no reliable way to keep track of stats, platform can choose not to expose it. If a platform is exposing inaccurate stats via this ACPI interface, it is breaking the spec. > 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. These fields has the same utility/use-cases as the usage & time fields in cpuidle sysfs, but provides more granularity - idle stats for different levels hierarchy and accurate idle stats for states that require platform co-ordination. The argument for having a single sysfs file per node was that reading individual files might get expensive to get a snapshot(not the other way around). But, that argument was weak as we typically read these only in debug settings and not that often during runtime. So, the summary_stats file was removed and went with one value per file. -- Thanks, Prashanth -- 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
