On Fri, 19 Jul 2013, Chen Gang F T wrote:
> > The fundamental issue is that typically ints are used for flags and I
> > would like to keep it that way. Changing the constants in slab.h and the
> > allocator code to be unsigned int instead of unsigned long wont be that
> > much of a deal.
> >
>
> At least, we need use 'unsigned' instead of 'signed'.
Ok.
> Hmm... Things maybe seem more complex, please see bellow:
>
> For 'SLAB_RED_ZONE' (or the other constants), they also can be assigned
> to "struct kmem_cache" member variable 'flags'.
>
> But for "struct kmem_cache", it has 2 different definitions, they share
> with the 'SLAB_RED_ZONE' (or the other constants).
>
> One defines 'flags' as 'unsigned int' in "include/linux/slab_def.h"
>
> 16 /*
> 17 * struct kmem_cache
> 18 *
> 19 * manages a cache.
> 20 */
> 21
> 22 struct kmem_cache {
> 23 /* 1) Cache tunables. Protected by cache_chain_mutex */
> 24 unsigned int batchcount;
> 25 unsigned int limit;
> 26 unsigned int shared;
> 27
> 28 unsigned int size;
> 29 u32 reciprocal_buffer_size;
> 30 /* 2) touched by every alloc & free from the backend */
> 31
> 32 unsigned int flags; /* constant flags */
> 33 unsigned int num; /* # of objs per slab */
> ...
>
> The other defines 'flags' as 'unsigned long' in "include/linux/slub_def.h"
> (but from its comments, it even says it is for 'Slab' cache management !!)
SLUB is slab allocator so there is nothing wrong with that.
> Maybe it is also related with our discussion ('unsigned int' or 'unsigned long') ?
Well we can make this uniformly unsigned int or long I guess. What would
be the benefits of one vs the other?
--
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>