On Fri, 17 Nov 2017, Mathieu Desnoyers wrote: > ----- On Nov 17, 2017, at 5:09 AM, Thomas Gleixner tglx@xxxxxxxxxxxxx wrote: > 7) Allow libraries with multi-part algorithms to work on same per-cpu > data without affecting the allowed cpu mask > > I stumbled on an interesting use-case within the lttng-ust tracer > per-cpu buffers: the algorithm needs to update a "reserve" counter, > serialize data into the buffer, and then update a "commit" counter > _on the same per-cpu buffer_. My goal is to use rseq for both reserve > and commit. > > Clearly, if rseq reserve fails, the algorithm can retry on a different > per-cpu buffer. However, it's not that easy for the commit. It needs to > be performed on the same per-cpu buffer as the reserve. > > The cpu_opv system call solves that problem by receiving the cpu number > on which the operation needs to be performed as argument. It can push > the task to the right CPU if needed, and perform the operations there > with preemption disabled. If your transaction cannot be done in one go, then abusing that byte code interpreter for concluding it is just hillarious. That whole exercise is a gazillion times slower than the atomic operations which are neccesary to do it without all that. I'm even more convinced now that this is overengineered beyond repair. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
