On Tue, 22 Feb 2022 00:57:02 -0800, Andi Shyti wrote: > Old thread, new comment below at the bottom. Please take a look. Thanks. > Hi Tvrtko and Joonas, > > > > > > > Now tiles have their own sysfs interfaces under the gt/ > > > > > > directory. Because RC6 is a property that can be configured on a > > > > > > tile basis, then each tile should have its own interface > > > > > > > > > > > > The new sysfs structure will have a similar layout for the 4 tile > > > > > > case: > > > > > > > > > > > > /sys/.../card0 > > > > > > \u251c\u2500\u2500 gt > > > > > > \u2502 \u251c\u2500\u2500 gt0 > > > > > > \u2502 \u2502 \u251c\u2500\u2500 id > > > > > > \u2502 \u2502 \u251c\u2500\u2500 rc6_enable > > > > > > \u2502 \u2502 \u251c\u2500\u2500 rc6_residency_ms > > > > > > . . . > > > > > > . . . > > > > > > . . > > > > > > \u2502 \u2514\u2500\u2500 gtN > > > > > > \u2502 \u251c\u2500\u2500 id > > > > > > \u2502 \u251c\u2500\u2500 rc6_enable > > > > > > \u2502 \u251c\u2500\u2500 rc6_residency_ms > > > > > > \u2502 . > > > > > > \u2502 . > > > > > > \u2502 > > > > > > \u2514\u2500\u2500 power/ -+ > > > > > > \u251c\u2500\u2500 rc6_enable | Original interface > > > > > > \u251c\u2500\u2500 rc6_residency_ms +-> kept as existing ABI; > > > > > > . | it multiplexes over > > > > > > . | the GTs > > > > > > -+ > > > > > > > > > > > > The existing interfaces have been kept in their original location > > > > > > to preserve the existing ABI. They act on all the GTs: when > > > > > > reading they provide the average value from all the GTs. > > > > > > > > > > Average feels very odd to me. I'd ask if we can get away providing an errno > > > > > instead? Or tile zero data? > > > > > > Tile zero data is always wrong, in my opinion. If we have round-robin > > > scaling workloads like some media cases, part of the system load might > > > just disappear when it goes to tile 1. > > > > I was thinking that in conjunction with deprecated log message it wouldn't > > be wrong - I mean if the route take was to eventually retire the legacy > > files altogether. > > that's a good point... do we want to treat the legacy interfaces > as an error or do we want to make them a feature? As the > discussion is turning those interfaces are becoming a feature. > But what are we going to do with the coming interfaces? > > E.g. in the future we will have the rc6_enable/disable that can > be a command, so that we will add the "_store" interface per > tile. What are we going to do with the above interfaces? Are we > going to add a multiplexed command as well? > > > > When we have frequency readbacks without control, returning MAX() across > > > tiles would be the logical thing. The fact that parts of the hardware can > > > be clocked lower when one part is fully utilized is the "new feature". > > > > > > After that we're only really left with the rc6_residency_ms. And that is > > > the tough one. I'm inclined that MIN() across tiles would be the right > > > answer. If you are fully utilizing a single tile, you should be able to > > > see it. > > > So we have MIN, AVG or SUM, or errno, or remove the file (which is > > just a different kind of errno?) to choose from. :) > > in this case it would just be MIN and MAX. At the end we have > here only two types of interface: frequencies and residency_ms. > For the first type we would use 'max', for the second 'min'. We have the comment below from Lowren about this about showing MAX for freq. Could someone reply. Thanks. On Sun, 06 Nov 2022 08:54:04 -0800, Lawson, Lowren H wrote: Why show maximum? Wouldnʼt average be more accurate to the user experience? As a user, I expect the ʽcardʼ frequency to be relatively accurate to the entire card. If I see 1.6GHz, but the card is behaving as if itʼs running a 1.0 & 1.6GHz on the different compute tiles, Iʼm going to see a massive decrease in compute workload performance while at ʽmaximumʼ frequency.
