On Thu, Jun 20, 2013 at 5:05 PM, Christoph Lameter <cl@xxxxxxxxx> wrote:
>
> On Wed, 19 Jun 2013, Gilad Ben-Yossef wrote:
>
> > +static void vmstat_update(struct work_struct *w)
> > +{
> > + int cpu, this_cpu = smp_processor_id();
> > +
> > + if (unlikely(this_cpu == vmstat_monitor_cpu))
> > + for_each_cpu_not(cpu, &vmstat_cpus)
> > + if (need_vmstat(cpu))
> > + start_cpu_timer(cpu);
> > +
> > + if (likely(refresh_cpu_vm_stats(this_cpu) || (this_cpu ==
> > vmstat_monitor_cpu)))
> > + schedule_delayed_work(&__get_cpu_var(vmstat_work),
> > +
> > round_jiffies_relative(sysctl_stat_interval));
> > + else
> > + cpumask_clear_cpu(this_cpu, &vmstat_cpus);
>
> The clearing of vmstat_cpus could be avoided if this processor is not
> running tickless. Frequent updates to vmstat_cpus could become an issue.
I like the idea of tying the vmstat disabling to the tickless logic
but I seem to have run
into a bit of a chicken and egg problem here:
vmstat_update runs from the vmstat work queue item by the workqueue
kernel thread.
If this code is running, it means there are at least two schedulable tasks:
1. The workqueue kernel thread, because it is running.
2. At least one more task, otherwise were were in idle and the
workqueue kernel thread
would not execute this work item.
Unfortunately, having two schedulable tasks means we're not running
tickless, so the check
will never trigger - or have I've missed something obvious?
Thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
gilad@xxxxxxxxxxxxx
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com
"If you take a class in large-scale robotics, can you end up in a situation
where the homework eats your dog?"
-- Jean-Baptiste Queru
--
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>