On Wed, 9 Sep 2015, Paul E. McKenney wrote: > > > > A processor that can randomly defer writes to cachelines in the face of > > > > other processors owning cachelines exclusively does not seem sane to me. > > > > In fact its no longer exclusive. > > > > > > Welcome to the wonderful world of store buffers, which are present even > > > on strongly ordered systems such as x86 and the mainframe. > > > > Store buffers hold complete cachelines that have been written to by a > > processor. > > In many cases, partial cachelines. If the cacheline is not available > locally, the processor cannot know the contents of the rest of the cache > line, only the contents of the portion that it recently stored into. For a partial cacheline it would have to read the rest of the cacheline before updating. And I would expect the processor to have exclusive access to the cacheline that is held in a store buffer. If not then there is trouble afoot. > > Hmmm... Guess I need to think more about this. Dont know the > > detail here on how they interact with cacheline exclusivity and stuff. > > A large number of stores to the same variable can happen concurrently, > and the system can stitch together the order of these stores after > the fact. Well thats what I know. The exact way the store buffers interact with cache coherency is what I do not know. > > > > > Sounds like the atomic_read needs more barriers. > > > > > > We all know that this won't happen. > > > > Well then welcome to the wonderful world of a broken kernel. Still > > wondering what this has to do with slab allocators. > > The concern I have is that the compiler might be able to reorder the > running CPU's last accesses to an object that is to be kfree()ed with > kfree()'s accesses. The issue being that the compiler is within its > rights to assume pointers to different types don't alias unless one of the > types is char * (or some such, Dmitry can correct me if I am confused). Hmmm... Yeah if one assumes that the object is going to be handled by a different processor then that is a valid concern but if its on the same processor then the guarantee is that the changes become visible to the exeucting thread in program order. That is enough. The transfer to another processor is guarded by locks and I think that those are enough to ensure that the cachelines become visible in a controlled fashion. -- 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>