> As I understand this rewrite aims to support the new file
> hierarchy and to be able to have higher level files contain the sum of
> the files below. I do not think a rewrite is necessary to
> support this. I do continue to believe that the previous SNC enabling
> is appropriate and as I understand support for this new display to user
> space can be added to it. For example, could this not be accomplished
> by adding one new member to struct rdt_resource that specifies the scope at
> which to display the monitor data to user space? mkdir_mondata_subdir() can
> use this field to decide how to create the files ... if the "display"
> scope is the same as the monitoring scope then files are created as
> it is now, if the "display" scope is different (required to be a superset)
> then the files are created within a directory that matches the "display"
> scope. I do not see why it would be required to have to work from a
> stored CPU mask to determine relationships. I believe the id of the
> "display" scope to create a sub-directory in can be determined dynamically
> at this time. Similarly, the metadata of the files are used to indicate
> when a sum is required.

Reinette,

I was concerned about dynamically figuring out the relationships. In
particular I thought it would be much easier to track addition/removal
of domains at both SNC node and L3 cache level if I used the existing
cpu hotplug tracking functions. Hence separate rdt_resources for each.

But after reading your suggestions above, I experimented with building
on top of the v17 series. It doesn't look anywhere as complex as I had
imagined. I'm going to pursue that today.

Thanks

-Tony