On Wed, Apr 05, 2023 at 09:54:57PM +0200, Peter Zijlstra wrote: > On Wed, Apr 05, 2023 at 04:43:14PM -0300, Marcelo Tosatti wrote: > > > Two points: > > > > 1) For a virtualized system, the overhead is not only of executing the > > IPI but: > > > > VM-exit > > run VM-exit code in host > > handle IPI > > run VM-entry code in host > > VM-entry > > I thought we could do IPIs without VMexit these days?
Yes, IPIs to vCPU (guest context). In this case we can consider an IPI to the host pCPU (which requires VM-exit from guest context). > Also virt... /me walks away. > > > 2) Depends on the application and the definition of "occasional". > > > > For certain types of applications (for example PLC software or > > RAN processing), upon occurrence of an event, it is necessary to > > complete a certain task in a maximum amount of time (deadline). > > If the application is properly NOHZ_FULL and never does a kernel entry, > it will never get that IPI. If it is a pile of shit and does kernel > entries while it pretends to be NOHZ_FULL it gets to keep the pieces and > no amount of crying will get me to care. I suppose its common practice to use certain system calls in latency sensitive applications, for example nanosleep. Some examples: 1) cyclictest (nanosleep) 2) PLC programs (nanosleep) A system call does not necessarily have to take locks, does it ? Or even if application does system calls, but runs under a VM, then you are requiring it to never VM-exit. This reduces the flexibility of developing such applications.
