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.
> 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.
> > 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.
Thanks.
--
tejun
