On Mon, May 18, 2020 at 12:42:54PM +0200, Thomas Gleixner wrote: > 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. I guess I misunderstood your point, sorry for that. The requirement is just that the request needs to be allocated on one online CPU after INACTIVE is set, and we can use a workqueue to do that. > > >> 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. We do want to avoid the cost of any lock, because it is in the fast IO path. Looks preempt_disable in patch 7 can't be avoided. Thanks, Ming
