On Fri, Jul 24, 2015 at 12:55:35PM -0400, Chris Metcalf wrote:
> On 07/23/2015 12:42 PM, Frederic Weisbecker wrote:
> >+unsigned long __tick_nohz_set_tick_dependency(enum tick_dependency_bit bit,
> >+                                          unsigned long *dep)
> >+{
> >+    unsigned long prev;
> >+    unsigned long old = *dep;
> >+    unsigned long mask = BIT_MASK(bit);
> >+
> >+    while ((prev = cmpxchg(dep, old, old | mask)) != old) {
> >+            old = prev;
> >+            cpu_relax();
> >+    }
> >+
> >+    return prev;
> >+}
> 
> Why not use set_bit() here?  It is suitably atomic.

Because I don't want to send an IPI if the CPU already had bits set in
the dependency.

Ideally I need something like test_and_set_bit() but which returns the
whole previous value and not just the previous value of the bit.

> 
> >+            /*
> >+            * We need the IPIs to be sent from sane process context.
> >+            * The posix cpu timers are always set with irqs disabled.
> >+            */
> 
> The block comment indentation is not quite right here.

Right.

> 
> >+void tick_nohz_set_tick_dependency_cpu(enum tick_dependency_bit bit, int 
> >cpu)
> >+{
> >+    unsigned long prev;
> >+    struct tick_sched *ts;
> >+
> >+    ts = per_cpu_ptr(&tick_cpu_sched, cpu);
> >+
> >+    prev = __tick_nohz_set_tick_dependency(bit, &ts->tick_dependency);
> >+    if (!prev)
> >+            tick_nohz_full_kick_cpu(cpu);
> >+}
> 
> I could imagine arguments for a WARN_ON() if cpu == smp_processor_id() here,
> since then you should be using the _thiscpu() variant.
> Or, you could transparently call the _thiscpu() variant in that case.
> I think some comment explaining why the approach you chose is better
> than those alternatives would be helpful here, perhaps.

It's fine to use this variant for local dependency but if you want it to
be NMI safe you need the _this_cpu() version. perf events require it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to