Messages in this thread | | | Date | Thu, 1 Dec 2011 14:56:23 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] specific do_timer_cpu value for nohz off mode |
| |
On Thu, 1 Dec 2011 10:37:40 -0600 Dimitri Sivanich <sivanich@sgi.com> wrote:
> +static ssize_t sysfs_store_do_timer_cpu(struct sys_device *dev, > + struct sysdev_attribute *attr, > + const char *buf, size_t size) > +{ > + struct sysdev_ext_attribute *ea = SYSDEV_TO_EXT_ATTR(attr); > + unsigned int new; > + int rv; > + > +#ifdef CONFIG_NO_HZ > + /* nohz mode not supported */ > + if (tick_nohz_enabled) > + return -EINVAL; > +#endif > + > + rv = kstrtouint(buf, 0, &new); > + if (rv) > + return rv; > + > + /* Protect against cpu-hotplug */ > + get_online_cpus(); > + > + if (new >= nr_cpu_ids || !cpu_online(new)) { > + put_online_cpus(); > + return -ERANGE; > + } > + > + *(unsigned int *)(ea->var) = new; > + > + put_online_cpus(); > + > + return size; > +}
OK, I think this fixes one race. We modify tick_do_timer_cpu inside get_online_cpus(). If that cpu goes offline then tick_handover_do_timer() will correctly hand the timer functions over to a new CPU, and tick_handover_do_timer() runs in the CPU hotplug handler which I assume is locked by get_online_cpus(). Please check all this.
Now, the above code can alter tick_do_timer_cpu while a timer interrupt is actually executing on another CPU. Will this disrupt aything? I think it might cause problems. If we take an interrupt on CPU 5 and that CPU enters tick_periodic() and another CPU alters tick_do_timer_cpu from 5 to 4 at exactly the correct time, tick_periodic() might fail to run do_timer(). Or it might run do_timer() on both CPUs 4 and 5 concurrently?
| |