Ming Lei <ming.lei@xxxxxxxxxx> writes: > On Mon, May 18, 2020 at 12:42:54PM +0200, Thomas Gleixner wrote: >> Ming Lei <ming.lei@xxxxxxxxxx> writes: >> > 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. That'd be great. >> >> 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. Well are you concerned about preemption or do you just need to make sure that the task can't be migrated? Thanks, tglx
