Hi Sebastian, On Fri, Feb 11, 2022 at 3:51 PM Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > > Unfortunately, though, I think disabling migration is required. Sultan > > (CC'd) found that these workqueues can migrate even midway through > > running. And generally the whole idea is to keep this on the *same* > > CPU so that we don't have to introduce locks and synchronization. > > They can't. Your workqueue is not unbound _and_ you specify a specific > CPU instead of WORK_CPU_UNBOUND (or an offlined CPU). > The only way it can migrate is if the CPU goes down while the worker is > running (or before it had a chance I think) which forces the scheduler > to break its (worker's) CPU affinity and move it to another CPU. Right, but the CPU could come back up while the worker is running on the wrong CPU, and then kaboom. Anyway, the migration_disable() window is very, very small - a few instructions at most with no loops. I think it'll be fine. > > I'll add comments around the acquire/release. The remaining question > > I believe is: would you prefer disabing irqs during the 2 word memcpy, > > or this counter double read loop? > > I would prefer the cmpxchg I'll do the cmpxchg and send you a v+1. Sorry it wasn't in the last one. It only now clicked with me what that code would look like, after I stepped away from the screen for a bit to defrobulate my brains. Jason
