On 3/20/24 05:09, Huang, Kai wrote: > I can try to do if you guys believe this should be done, and should be done > earlier than later, but I am not sure _ANY_ optimization around SEAMCALL will > have meaningful performance improvement. I don't think Sean had performance concerns. I think he was having a justifiably violent reaction to how much more complicated the generated code is to do a SEAMCALL versus a good ol' KVM hypercall. "Complicated" in this case means lots more instructions and control flow. That's slower, sure, but the main impact is that when you go to debug it, it's *MUCH* harder to debug the SEAMCALL entry assembly than a KVM hypercall. My takeaway from this, though, is that we are relying on the compiler for a *LOT*. There are also so many levels in the helpers that it's hard to avoid silly things like two _separate_ retry loops. We should probably be looking at the generated code a _bit_ more often than never, and it's OK to tinker a _bit_ to make things out-of-line or make sure that the compiler optimizes everything that we think that it should. Also remember that there are very fun tools out there that can make this much easier than recompiling the kernel a billion times: https://godbolt.org/z/8ooE4d465
