On 21/03/2024 4:07 am, Dave Hansen wrote:
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.
Ah, I automatically linked "generating better code" to "in order to have
better performance". My bad.
"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.
Yeah, agreed.
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
Ah, this is useful. Thanks for sharing :-)
