On Mon, 14 Jul 2014, Paul E. McKenney wrote: > Here is the sort of thing that I would be concerned about: > > p = alloc_percpu(struct foo); > for_each_possible_cpu(cpu) > initialize(per_cpu_ptr(p, cpu); > gp = p; > > We clearly need a memory barrier in there somewhere, and it cannot > be buried in alloc_percpu(). Some cases avoid trouble due to locking, > for example, initialize() might acquire a per-CPU lock and later uses > might acquire that same lock. Clearly, use of a global lock would not > be helpful from a scalability viewpoint.
The knowledge about the offset p is not available before gp is assigned to. gp usually is part of a struct that contains some form of serialization. F.e. in the slab allocators there is a kmem_cache structure that contains gp. After alloc_percpu() and other preparatory work the structure is inserted into a linked list while holding the global semaphore (slab_mutex). After release of the semaphore the kmem_cache address is passed to the subsystem. Then other processors can potentially use that new kmem_cache structure to access new percpu data related to the new cache. There is no scalability issue for the initialization since there cannot be a concurrent access since the offset of the percpu value is not known by other processors at that point. -- 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/
