Ming Lei <ming.lei@xxxxxxxxxx> writes: > On Mon, May 18, 2020 at 10:32:22AM +0200, Thomas Gleixner wrote: >> Christoph Hellwig <hch@xxxxxx> writes: >> Is this absolutely necessary to be a smp function call? That's going to > > I think it is. > > Request is bound to the allocation CPU and the hw queue(hctx) which is > mapped from the allocation CPU. > > If request is allocated from one cpu which is going to offline, we can't > handle that easily. That's a pretty handwavy explanation and does not give any reason why this needs to be a smp function call and cannot be solved otherwise, e.g. by delegating this to a work queue. >> be problematic vs. RT. Same applies to the explicit preempt_disable() in >> patch 7. > > I think it is true and the reason is same too, but the period is quite short, > and it is just taken for iterating several bitmaps for finding one free bit. And takes spinlocks along the way.... See: https://www.kernel.org/doc/html/latest/locking/locktypes.html for a full explanation why this can't work on RT. And that's the same reason why the smp function call will fall apart on a RT enabled kernel. Thanks, tglx
