On Tue, Apr 21, 2020 at 03:39:47PM +0200, Sebastian Andrzej Siewior wrote: > 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). I am guessing that by "which is not yet needed" you were meaning that it is not absolutely necessary to extend the length of the critical section. Please correct me if my guess is wrong. In the meantime, plunging ahead... One approach might be to move queue_work() and friends out of the critical section, but only enable interrupts between the two critical sections under CONFIG_PREEMPT_RT_FULL. Would that be a reasonable approach? Thanx, Paul
