On Thu, Nov 14, 2019 at 3:27 AM Jonathan Cameron <jonathan.cameron@xxxxxxxxxx> wrote: [..] > Hi Dan, > > Agreed that it makes sense to expand how we describe these cases a bit. > To make sure I've understood correctly let me paraphrase what you > are proposing (and tweak it a bit ;) > > Assuming for this purpose we don't put GIs in CPU nodes as that makes > for really fiddly explanation. In reality the code will need to handle > that. > > 1) Leave access0 as it currently is with this series - so continue to > not distinguish between CPU nodes and Generic Initator containing ones? Yes, but with the caveat that I think 2) also needs to be part of the series before it goes upstream. I.e. don't regress the amount of default information just because a generic initiator is present. > 2) Add access 1 which is effectively access0 ignoring Generic Initiators? Effectively yes, but I'd say it differently. Always display the access class for the local initiator as defined by the HMAT as access0, but also include the "local" cpu node. > My feeling is that any existing users of access0 are definitely not going > to be expecting generic initiators, so we might want to do this the other > way around. access0 is only CPUs and memory, access1 is including > generic initiators. If there are no GIs don't expose access1 at all? There are no consumers of the information that I know of, so I do not see the risk of regression. > For now we could simply block the GI visibility in access0 and deal > with access1 as a separate series. I suspect we will get push back > as there are no known users of our new access1 so it may take a while > to prove utility and get it accepted. The problem is that HMAT gives an unequivocal answer for "local" because it lists it in the table explicitly. Everything else is a subjective determination from parsing the performance data and picking a metric. If access0 is a GI, then let sysfs just reflect that truth.
