> In the context of restartable sequences [1] [2], the goal is to turn > atomic operations on per-cpu data into a sequence of simple load/store > operations. Therefore, improving getcpu from 12ns to 0.3ns will have a
I don't think LSL is 12ns. It's a few cycles. > Moreover, AFAIU, restartable sequences cannot do the function call > required by the vdso while within the c.s.: those need to entirely fit > within an inline assembly. So this CPU number caching actually enables > restartable sequences, whereas the vdso approach cannot be used in that > context. You can use the LSL directly though. In practice people already rely on it (and it's very cheap on the kernel side), so it's a defacto ABI and could be documented. So it's not function call vs load, but LSL vs load. > > Finally, even if overall this new system call is not deemed sufficiently > interesting on x86, other popular architectures such as ARM32 don't have > any vDSO for getcpu at the moment, mainly because they don't have similar > segment selector tricks, and I'm not aware of other solutions than caching Has that been confirmed by architecture experts? Maybe there is some trick there too. > I suspect that most of the difference between the vDSO approach and > CPU number caching is simply the function call required for the vDSO. > I doubt there is much to be done on this front. Not sure about that. Basic function calls are not that expensive. Right now there is some baggage but that could be optimized. The only unavoidable overhead would be the ABI register clobbering. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
