Hi John, ... > > > > + > > > > + /* > > > > + * Wa_14019159160: disable the automatic CCS load balancing > > > I'm still a bit concerned that this doesn't really match what this > > > specific workaround is asking us to do. There seems to be an agreement > > > on various internal email threads that we need to disable load > > > balancing, but there's no single specific workaround that officially > > > documents that decision. > > > > > > This specific workaround asks us to do a bunch of different things, and > > > the third item it asks for is to disable load balancing in very specific > > > cases (i.e., while the RCS is active at the same time as one or more CCS > > > engines). Taking this workaround in isolation, it would be valid to > > > keep load balancing active if you were just using the CCS engines and > > > leaving the RCS idle, or if balancing was turned on/off by the GuC > > > scheduler according to engine use at the moment, as the documented > > > workaround seems to assume will be the case. > > > > > > So in general I think we do need to disable load balancing based on > > > other offline discussion, but blaming that entire change on > > > Wa_14019159160 seems a bit questionable since it's not really what this > > > specific workaround is asking us to do and someone may come back and try > > > to "correct" the implementation of this workaround in the future without > > > realizing there are other factors too. It would be great if we could > > > get hardware teams to properly document this expectation somewhere > > > (either in a separate dedicated workaround, or in the MMIO tuning guide) > > > so that we'll have a more direct and authoritative source for such a > > > large behavioral change. > > On one had I think you are right, on the other hand I think this > > workaround has not properly developed in what we have been > > describing later. > I think it is not so much that the w/a is 'not properly developed'. It's > more that this w/a plus others when taken in combination plus knowledge of > future directions has led to an architectural decision that is beyond the > scope of the w/a. > > As such, I think Matt is definitely correct. Tagging a code change with a > w/a number when that change does something very different to what is > described in the w/a is wrong and a maintenance issue waiting to happen. > > At the very least, you should just put in a comment explaining the > situation. E.g.: > > /* > * Wa_14019159160: This w/a plus others cause significant issues with the use of > * load balancing. Hence an architectural level decision was taking to simply > * disable automatic CCS load balancing completely. > */ Good suggestion! I will anyway check tomorrow with Joonas if it's worth the effort to set up a new "software" workaround. Thanks, Andi
