Srikar Dronamraju <sri...@linux.vnet.ibm.com> writes: > * Michael Ellerman <m...@ellerman.id.au> [2020-07-31 17:49:55]: > >> Srikar Dronamraju <sri...@linux.vnet.ibm.com> writes: >> > Add support for grouping cores based on the device-tree classification. >> > - The last domain in the associativity domains always refers to the >> > core. >> > - If primary reference domain happens to be the penultimate domain in >> > the associativity domains device-tree property, then there are no >> > coregroups. However if its not a penultimate domain, then there are >> > coregroups. There can be more than one coregroup. For now we would be >> > interested in the last or the smallest coregroups. >> >> This still doesn't tell me what a coregroup actually represents. >> >> I get that it's a grouping of cores, and that the device tree specifies >> it for us, but grouping based on what? > > We have just abstracted the fact that we are creating a sub-group of cores > within a DIE. We are limiting to one sub-group per core. However this would > allow the firmware the flexibility to vary the grouping. Once the firmware > starts using this group, we could add more code to detect the type of > grouping and adjust the sd domain flags accordingly.
OK. That's good info to have in the change log. >> I think the answer is we aren't being told by firmware, it's just a >> grouping based on some opaque performance characteristic and we just >> have to take that as given. >> > > This is partially true. At this time, we dont have firmwares that can > exploit this code. Once the firmwares start using this grouping, we could > add more code to align the grouping to the scheduler topology. > >> But please explain that clearly in the change log and the code comments. >> > > Okay, I will do the needful. Thanks. cheers
