I've been wondering whether the SNC patches were creating way too much infrastructure that isn't generally useful. Specifically the capability for a reactrl resource to have different scope for monitoring and control functions. That seems like a very strange thing. History here is that Intel CMT, MBM and L3 CAT features arrived in quick succession, closely followed by MBA and then L2 CAT. At the time it made sense for the "L3" resource to cover all of CMT, MBM and L3 CAT. That became slightly odd when MBA (another L3 scoped resource) was added. It was given its own "struct rdt_resource". AMD later added SMBA as yet another L3-scoped resource with its own "struct resource". I wondered how the SNC series would look if I went back to an approach from one of the earlier versions. In that one I created a new resource for SNC monitoring that was NODE scoped. And then made all the CMT and MBM code switch over to using that one when SNC was enabled. That was a bit hacky, and I moved from there to the dual domain lists per resource. I just tried out an approach the split the RDT_RESOURCE_L3 resource into separate resources, one for control, one for monitoring. It makes the code much simpler: 8 files changed, 235 insertions(+), 30 deletions(-) [1] vs. 9 files changed, 629 insertions(+), 282 deletions(-) Tradeoffs: The complex series (posted as v14) cleanly split the "rdt_domain" structure into two. So it no longer carried all the fields needed for both control and monitor, even though only one set was ever used. But the cost was a lot of code churn that may never be useful for anything other than SNC. On non-SNC systems the new series produces separate linked lists of domains for L3 control & monitor, even though the lists are the same, and the domain structures still carry all fields for both control and monitor functions. Question: Does anyone think that single domain with different scope for control and monitor is inherently more useful than two separate domains? While I get this sorted out, maybe Boris should take James next set of MPAM patches as they are, instead of on top of the complex SNC series. -Tony [1] I'll post this set just as soon as I can get time on and SNC machine to make sure they actually work.
