All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Gang F T <chen.gang.flying.transformer@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: Chen Gang <gang.chen@asianux.com>,
	Pekka Enberg <penberg@kernel.org>,
	mpm@selenic.com, linux-mm@kvack.org
Subject: Re: [PATCH] mm/slub.c: use 'unsigned long' instead of 'int' for variable 'slub_debug'
Date: Fri, 19 Jul 2013 08:50:55 +0800	[thread overview]
Message-ID: <51E88D6F.3000905@gmail.com> (raw)
In-Reply-To: <0000013ff204c901-636c5864-ec23-4c31-a308-d7fd58016364-000000@email.amazonses.com>

On 07/18/2013 09:42 PM, Christoph Lameter wrote:
> On Thu, 18 Jul 2013, Chen Gang wrote:
> 
>> On 07/17/2013 10:46 PM, Christoph Lameter wrote:
>>> On Tue, 16 Jul 2013, Chen Gang wrote:
>>>
>>>> If we really use 32-bit as unsigned number, better to use 'U' instead of
>>>> 'UL' (e.g. 0x80000000U instead of 0x80000000UL).
>>>>
>>>> Since it is unsigned 32-bit number, it is better to use 'unsigned int'
>>>> instead of 'int', which can avoid related warnings if "EXTRA_CFLAGS=-W".
>>>
>>> Ok could you go through the kernel source and change that?
>>>
>>
>> Yeah, thanks, I should do it.
>>
>> Hmm... for each case of this issue, it need communicate with (review by)
>> various related maintainers.
>>
>> So, I think one patch for one variable (and related macro contents) is
>> enough.
>>
>> Is it OK ?
> 
> 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'.

e.g.
----------------------------diff begin---------------------------------

diff --git a/mm/slub.c b/mm/slub.c
index 2b02d66..7111d7a 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -452,9 +452,9 @@ static void get_map(struct kmem_cache *s, struct page *page, unsigned long *map)
  * Debug settings:
  */
 #ifdef CONFIG_SLUB_DEBUG_ON
-static int slub_debug = DEBUG_DEFAULT_FLAGS;
+static unsigned int slub_debug = DEBUG_DEFAULT_FLAGS;
 #else
-static int slub_debug;
+static unsigned int slub_debug;
 #endif
 
 static char *slub_debug_slabs;

----------------------------diff end-----------------------------------
 
> Will the code then be clean enough for you?
> 

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

 65 /*
 66  * Slab cache management.
 67  */
 68 struct kmem_cache {
 69         struct kmem_cache_cpu __percpu *cpu_slab;
 70         /* Used for retriving partial slabs etc */
 71         unsigned long flags;
 72         unsigned long min_partial;
 73         int size;               /* The size of an object including meta data */
 74         int object_size;        /* The size of an object without meta data */
 75         int offset;             /* Free pointer offset. */
 76         int cpu_partial;        /* Number of per cpu partial objects to keep around */
 77         struct kmem_cache_order_objects oo;
...


Maybe it is also related with our discussion ('unsigned int' or '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>
> 


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

  reply	other threads:[~2013-07-19  0:52 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-12  1:43 [PATCH] mm/slub.c: use 'unsigned long' instead of 'int' for variable 'slub_debug' Chen Gang
2013-07-12  3:27 ` [PATCH] mm/slub.c: beautify code of this file Chen Gang
2013-07-12 13:58   ` Christoph Lameter
2013-07-15  0:31     ` Chen Gang
2013-07-15  1:04     ` [PATCH 0/2] " Chen Gang
2013-07-15  1:05     ` [PATCH 1/2] mm/slub.c: beautify code for 80 column limitation and tab alignment Chen Gang
2013-07-15 14:19       ` Christoph Lameter
2013-07-16  0:55         ` Chen Gang
2013-07-15  1:06     ` [PATCH 2/2] mm/slub.c: beautify code for removing redundancy 'break' statement Chen Gang
2013-07-17  7:08       ` Pekka Enberg
2013-07-17 14:47       ` Christoph Lameter
2013-07-18  0:02         ` Chen Gang
2013-07-12 13:53 ` [PATCH] mm/slub.c: use 'unsigned long' instead of 'int' for variable 'slub_debug' Christoph Lameter
2013-07-15  0:19   ` Chen Gang
2013-07-15 14:17     ` Christoph Lameter
2013-07-16  0:53       ` Chen Gang
2013-07-17 14:46         ` Christoph Lameter
2013-07-18  0:13           ` Chen Gang
2013-07-18 13:42             ` Christoph Lameter
2013-07-19  0:50               ` Chen Gang F T [this message]
2013-07-19 14:00                 ` Christoph Lameter
2013-07-22  1:19                   ` Chen Gang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51E88D6F.3000905@gmail.com \
    --to=chen.gang.flying.transformer@gmail.com \
    --cc=cl@linux.com \
    --cc=gang.chen@asianux.com \
    --cc=linux-mm@kvack.org \
    --cc=mpm@selenic.com \
    --cc=penberg@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.