Re: vmstat: On demand vmstat workers V4

[Christoph Lameter]

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/