On 4/27/2017 3:16 AM, Sudeep Holla wrote: > > On 27/04/17 00:21, Prakash, Prashanth wrote: >> Hi Sudeep, >> >> On 4/25/2017 4:28 AM, Sudeep Holla wrote: >>>> With hierarchy, it is possible to get information about relationship between cpus >>>> and higher order shared resources. If we flatten the hierarchy we lose information >>>> about relationships and it gets a little hard to clearly represent the idle states of >>>> shared resources and which cpus share those resources. >>>> >>> No, what I meant is to have complete information broken down to the >>> lowest possible level, but just one file access to get that information. >>> >>> IIUC, you had some format already for summary_stat file, just extend >>> to get all the information you would get reading individual sysfs files >>> organized hierarchically. I don't think that should matter much as you >>> would have all these information, just the representation differs. I am >>> assuming all this data is not used/interpreted on the fly, but mostly >>> used offline for analysis. Otherwise it's already misuse and we don't >>> want to expose such user ABI IMO. >>> >>> Just to summarize, though I agree this LPI stats are more accurate and >>> more representative summary, I think it may fade away as we move towards >>> hardware controlled lower power states. Since we already have cpuidle >>> stats, I prefer to keep this LPI stats interface to userspace as simple >>> and minimal as possible and yet helpful to get all the information. >> Sounds good. I will remove summary_stats and make other changes based on >> feedback and post next rev. > I am sorry if I was not clear earlier, I was infact asking you what if > we just have single summary_stat file with all statistics broken down to > minuet details you want instead of creating the hierarchy of individual > files which you say has overhead to read. > > Do you process the stats on the fly when workload is running, I assume not. I don't see any use-cases for on the fly analysis. The most we might want to do it capture this data periodically and then post-process it to see how different phases of a workload did. The overhead of reading multiple files comes down what could be the duration between reads to this sysfs without drastically impacting the workload - so it is probably not such a big issue. While it is possible to simplify by having all the data aggregated into a single file at each level in the hierarchy, we end up trading some inefficiencies: - We are reducing the number of file access but increasing the amount of data read (which user-space may or may not be interested in), including re-reading the constant fields(desc, latency etc..) every time. - Adding all info on the same file increases the probability we might break userspace parsing of this single file when we want add a new piece of information. While this was possible earlier, the probability was little lower as it was restricted to only time and usage. - Another reason to avoid collapsing all the fields to single file is to keep it consistent with cpudile interface I was thinking about some of the above issues and when you mentioned simple and minimal, I interpreted it as lets keep the interface simple by removing summary_stats and few other fields we discussed. Sorry, my bad. -- 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
