On 04/10/2018 09:53 PM, Tejun Heo wrote: > Hello, > > On Tue, Apr 10, 2018 at 09:40:19PM +0200, Vlastimil Babka wrote: >> On 04/10/2018 04:12 PM, Christopher Lameter wrote: >>> On Tue, 10 Apr 2018, Vlastimil Babka wrote: >>> >>>> cache_reap() is initially scheduled in start_cpu_timer() via >>>> schedule_delayed_work_on(). But then the next iterations are scheduled via >>>> schedule_delayed_work(), thus using WORK_CPU_UNBOUND. >>> >>> That is a bug.. cache_reap must run on the same cpu since it deals with >>> the per cpu queues of the current cpu. Scheduled_delayed_work() used to >>> guarantee running on teh same cpu. >> >> Did it? When did it stop? (which stable kernels should we backport to?) > > It goes back to v4.5 - ef557180447f ("workqueue: schedule > WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs") which made > WQ_CPU_UNBOUND on percpu workqueues honor wq_unbound_cpusmask so that > cpu isolation works better. Unless the force_rr option or > unbound_cpumask is set, it still follows local cpu.
I see, thanks. >> So is my assumption correct that without specifying a CPU, the next work >> might be processed on a different cpu than the current one, *and also* >> be executed with a kthread/u* that can migrate to another cpu *in the >> middle of the work*? Tejun? > > For percpu work items, they'll keep executing on the same cpu it > started on unless the cpu goes down while executing. Right, but before this patch, with just schedule_delayed_work() i.e. non-percpu? If such work can migrate in the middle, the slab bug is potentially much more serious. >>> schedule_delayed_work_on(smp_processor_id(), work, >>> round_jiffies_relative(REAPTIMEOUT_AC)); >>> >>> instead all of the other changes? >> >> If we can rely on that 100%, sure. > > Yeah, you can. Great, thanks. > Thanks. >