Re: [PATCH] mm/slub.c: use 'unsigned long' instead of 'int' for variable 'slub_debug'

[Chen Gang <gang.chen@asianux.com>]

On 07/19/2013 10:00 PM, Christoph Lameter wrote:
> 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.
> 

OK, thanks.

>> 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?
> 

Yeah, need let the 2 'flags' with the same type: "make this uniformly
unsigned int or long".


Hmm... Flags variable is always the solid length variable, so it is not
suitable to use 'unsigned long' which length depends on 32/64 machine
automatically.

If the 'unsigned int' is not enough, we need use 'unsigned long long'
instead of. Else (it's enough), better to still use 'unsigned int' to
save memory usage.

'unsigned long' is useful(necessary) for some variables (e.g. address
related variables), but is not suitable for the always solid length
variable.


Thanks.
-- 
Chen Gang

--
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>