Messages in this thread | | | Date | Mon, 11 Jan 2021 13:50:52 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH -tip V3 0/8] workqueue: break affinity initiatively |
| |
On Mon, Jan 11, 2021 at 10:09:07AM -0800, Paul E. McKenney wrote: > On Mon, Jan 11, 2021 at 06:16:39PM +0100, Peter Zijlstra wrote: > > > > While thinking more about this, I'm thinking a big part of the problem > > is that we're not dinstinguishing between geniuine per-cpu kthreads and > > kthreads that just happen to be per-cpu. > > > > Geniuine per-cpu kthreads are kthread_bind() and have PF_NO_SETAFFINITY, > > but sadly a lot of non-per-cpu kthreads, that might happen to still be > > per-cpu also have that -- again workqueue does that even to it's unbound > > workers :-( > > > > Now, anything created by smpboot, is created through > > kthread_create_on_cpu() and that additionally sets to_kthread(p)->flags > > KTHREAD_IS_PER_CPU. > > > > And I'm thinking that might be sufficient, if we modify > > is_per_cpu_kthread() to check that, then we only match smpboot threads > > (which include the hotplug and stopper threads, but notably not the idle > > thread) > > > > Sadly it appears like io_uring() uses kthread_create_on_cpu() without > > then having any hotplug crud on, so that needs additinoal frobbing. > > > > Also, init_task is PF_KTHREAD but doesn't have a struct kthread on.. and > > I suppose bound workqueues don't go through this either. > > > > Let me rummage around a bit... > > > > This seems to not insta-explode... opinions? > > It passes quick tests on -rcu both with and without the rcutorture fixes, > which is encouraging. I will start a more vigorous test in about an hour.
And 672 ten-minute instances of RUDE01 passed with this patch applied and with my rcutorture patch reverted. So looking good, thank you!!!
Thanx, Paul
| |