On Wed, 20 Dec 2017, Matthew Wilcox wrote: > slub wants to atomically update both freelist and its counters, so it has > 96 bits of information to update atomically (on 64 bit), or 64 bits on > 32-bit machines. We don't have a 96-bit atomic-cmpxchg, but we do have > a 128-bit atomic-cmpxchg on some architectures. So _if_ we're going > to use cmpxchg_double(), then we need counters to be an unsigned long. > If we're not then counters needs to be an unsigned int so it doesn't > overlap with _refcount, which is not going to be protected by slab_lock. Almost correct. slab_lock is not used when double word cmpxchg is available on the architecture. > Now I look at it some more though, I wonder if it would hurt for counters > to always be unsigned long. There is no problem on 32-bit as long and int > are the same size. So on 64-bit, the cmpxchg_double path stays as it is. > There would then be the extra miniscule risk that __cmpxchg_double_slab() > fails due to a spurious _refcount modification due to an RCU-protected > pagecache lookup. And there are a few places that would be a 64-bit > load rather than a 32-bit load. Sounds good to me. > I think if I were doing slub, I'd put in 'unsigned int counters_32' > and 'unsigned long counters_64'. set_page_slub_counters() would then > become simply: > > page->counters_32 = counters_new; If counters is always the native word size then we would not need the 32 and 64 bit variants. Counters could always be unsigned long -- 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>
