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