On Thu, Nov 01, 2018 at 09:12:04AM +0800, Zeng, Star wrote: > > > I believe the performance data really depends on > > > 1. How many AsyncInterruptTransfer handlers (the number of USB keyboard > > > and/or USB bluetooth keyboard?) > > > 2. Data size (for flushing data from PCI controller specific address to > > > mapped system memory address *in original code*) > > > 3. The performance of IoMmu->SetAttribute (for example, the SetAttribute > > > operation on Intel VTd engine caused by the unmap and map for flushing > > > data > > > *in original code*, the SetAttribute operation on IntelVTd engine will > > > involve FlushPageTableMemory, InvalidatePageEntry and etc) > > > > > > > On an unrelated note to the concerns above: > > > > Why has a fundamental change to the behaviour of one of the industry > > > > standard drivers been pushed at the very end of the stable cycle? > > > > > > We thought it was a simple improvement but not fundamental change before > > > Eugene and Ard raised the concern. > > > > Understood. > > Thanks. :) > > > > > However, as it is changing the memory management behaviour of a core > > driver, I think it automatically qualifies as something that should > > only go in the week after a stable tag. > > > > We will need to have a closer look at the non-coherent case when Ard > > gets back (Monday). > > You mean Ard is on vacation and will be back next Monday.
Yes. > > If this version causes issues with non-coherent systems, we will need > > to revert it before the stable tag. We would then need to look into > > the best way to deal with the performance issues quoted above. > > I am glad to revert it if it has side effect. Is it possible someone could > have a quick check? Ard could. It would take me much longer :) Which is why I would prefer to wait until next week. Regards, Leif _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
