On Thu, 8 May 2014, Andrew Morton wrote: > Some explanation of the changes to kernel/time/tick-common.c would be > appropriate. I dropped those after the discussion related to housekeepig cpus. > > + cancel_delayed_work_sync(d); > > + cpumask_set_cpu(smp_processor_id(), monitored_cpus); > > + cpumask_clear_cpu(s, monitored_cpus); > > + INIT_DELAYED_WORK(d, vmstat_shepherd); > > INIT_DELAYED_WORK() seems inappropriate here. It's generally used for > once-off initialisation of a freshly allocated work item. Look at all > the stuff it does - do we really want to run debug_object_init() > against an active object? Well this function is the one off initialization. INIT_DEFERRABLE_WORK in vmstat_shepherd() is a case of repeatedly initializing the per cpu structure when the worker thread is started again. In order to remove that I would have to do a loop initializing the structures at startup time. In V4 there were different function depending on the processor and they could change. With the housekeeping processor fixed that is no longer the case. Should I loop over the whole structure and set the functions at init time? > > case CPU_DOWN_PREPARE_FROZEN: > > - cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu)); > > + if (!cpumask_test_cpu(cpu, monitored_cpus)) > > This test is inverted isn't it? If the monitoring cpu bit is not set then the worker thread is active and needs to be cancelled. There is a race here so I used test_and_clear here in the new revision. -- 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>