On Tue, 29 Jul 2014, Sasha Levin wrote: > > Index: linux/mm/vmstat.c > > =================================================================== > > --- linux.orig/mm/vmstat.c 2014-07-29 10:22:45.073884943 -0500 > > +++ linux/mm/vmstat.c 2014-07-29 10:34:45.083369228 -0500 > > @@ -1277,8 +1277,8 @@ static int vmstat_cpuup_callback(struct > > break; > > case CPU_DOWN_PREPARE: > > case CPU_DOWN_PREPARE_FROZEN: > > - cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu)); > > per_cpu(vmstat_work, cpu).work.func = NULL; > > + cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu)); > > break; > > case CPU_DOWN_FAILED: > > case CPU_DOWN_FAILED_FROZEN: > > > > I'm slightly confused here. The on demand vmstat workers patch did this: > > case CPU_DOWN_PREPARE_FROZEN: > - cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu)); > - per_cpu(vmstat_work, cpu).work.func = NULL; > + if (!cpumask_test_and_set_cpu(cpu, cpu_stat_off)) > + cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu)); > > So your new patch doesn't apply on top of it, and doesn't make sense before it. Tejun was looking at upsteram and so I fixed upstream ;-) Is it really necessary to set the work.func to NULL? If so then the work.func will have to be initialized when a processor is brought online. Canceling the work should be enough to disable the execution of the function. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>