On 2020-04-20 19:40:19 [+0200], Uladzislau Rezki wrote: > Paul, if move outside of the lock we may introduce unneeded migration > issues, plus it can introduce higher memory footprint(i have not tested). > I have described it in more detail earlier in this mail thread. I do not > think that waking up the work is an issue for RT from latency point of > view. But let's ask Sebastian to confirm. > > Sebastian, do you think that placing a work on current CPU is an issue? > If we do it under raw spinlock? I sent one simple patch to address the issues I see now. It was raised that the patch may introduce a performance regression (`may' since we had no numbers back it up) in case where we the context would be migrated from one CPU to another between "this" and "spin_lock". It was suggested to use migrate_disable() to avoid it. It was then decided to address possible future problems and make the lock raw which brings us here. Invoking queue_work() is not a problem locking wise. It does however extend the length of the critical section (which is not yet needed). > Thank you! > Sebastian
