On Thu, Jun 25, 2015 at 03:17:01PM -0400, Tejun Heo wrote:
> Hmmm... the only worry I have about this is people using it on u64 on
> 32bit machines. CPU local ops can do split updates on lower and upper
> halves and the remotely-read value will be surprising. We have the
> same issues w/ regular per_cpu accesses to but the summing function /
> macro is better at giving the false sense of security. Prolly
> limiting it upto ulong size is a good idea?
Agreed, luckily we already have the infrastructure for this, something
like so?
--- a/include/linux/percpu-defs.h
+++ b/include/linux/percpu-defs.h
@@ -287,6 +287,16 @@ do {
\
preempt_enable(); \
} while (0)
+#define per_cpu_sum(var) \
+({ \
+ typeof(var) __sum = 0; \
+ int cpu; \
+ compiletime_assert_atomic_type(__sum); \
+ for_each_possible_cpu(cpu) \
+ __sum += per_cpu(var, cpu); \
+ __sum; \
+})
+
/*
* Branching function to split up a function into a set of functions that
* are called for different scalar sizes of the objects handled.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
