On 2018-03-05 12:50 PM, Christian König wrote: >>> The easiest way to work around this to to add a separate IOCTL which >>> waits for VM updates to complete. Should be trivial to use >>> vm->last_update for this. >> For the cost of an extra system call. That means every GPU mapping >> operation now requires two system calls. With Spectre workarounds, that >> can be a lot more expensive. > > There is still very little overhead associated with that. > > And additional to this as long you actually need to wait it doesn't > matter if you wait directly in one system call or if you split it into > two. The time from the initial call to the end of the operation stays > the same. That's if you have waiting. For CPU page table updates, there is no waiting, so the extra system call is wasted. Another alternative would be to make the ioctl fail with -EINTR instead. That way the Thunk would be in charge of handling the restart, and we wouldn't have to pretend that no state was changed by the first call. > > You can then also pipeline multiple mappings and wait for all of them > to finish in the end. Our Thunk mapping function already bundles all the mappings it can do at once into a single ioctl. The Thunk API must guarantee that memory can be accessed when it returns. So we have no further room for improving the pipelining without changing the Thunk API semantics. Regards,  Felix > > Regards, > Christian.
