Someone wrote in ![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} jeffr_tech, |
IPI fundamentally expensive
An IPI is fundamentally expensive because it causes the destination CPU to trap. This is likely to take hundreds of cycles.
An IPI could be implemented nicely on the bus because it doesn't have to worry about cache coherency issues (on the other hand, CPU/bus designers have far far more motive to improve cache coherency than to improve IPI performance).
The ideal primitive would be a synchronous wait-for-interrupt-number instruction that would rather not trap but just return with a flag set if the given interrupt triggers. OTOH this might add additional complexity to the CPU's interrupt handling paths...
An IPI is fundamentally expensive because it causes the destination CPU to trap. This is likely to take hundreds of cycles.
An IPI could be implemented nicely on the bus because it doesn't have to worry about cache coherency issues (on the other hand, CPU/bus designers have far far more motive to improve cache coherency than to improve IPI performance).
The ideal primitive would be a synchronous wait-for-interrupt-number instruction that would rather not trap but just return with a flag set if the given interrupt triggers. OTOH this might add additional complexity to the CPU's interrupt handling paths...
