Re: [PATCH 5/8] mm: Introduce _slub_counter_t

[Christopher Lameter <cl@linux.com>]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>