Re: [RFC PATCH] mm: introduce N_LRU_MEMORY to distinguish between normal and movable memory

2012-08-10 Thread Christoph Lameter (Open Source)
On Fri, 10 Aug 2012, Hanjun Guo wrote: > On 2012/8/9 22:06, Christoph Lameter (Open Source) wrote: > > On Thu, 9 Aug 2012, Hanjun Guo wrote: > > > >> Now, We have node masks for both N_NORMAL_MEMORY and > >> N_HIGH_MEMORY to distinguish between normal and highm

Re: [RFC PATCH] mm: introduce N_LRU_MEMORY to distinguish between normal and movable memory

2012-08-10 Thread Christoph Lameter (Open Source)
On Fri, 10 Aug 2012, Hanjun Guo wrote: On 2012/8/9 22:06, Christoph Lameter (Open Source) wrote: On Thu, 9 Aug 2012, Hanjun Guo wrote: Now, We have node masks for both N_NORMAL_MEMORY and N_HIGH_MEMORY to distinguish between normal and highmem on platforms such as x86. But we still

Re: [PATCH v2] mm: Restructure kmem_cache_create() to move debug cache integrity checks into a new function

2012-08-09 Thread Christoph Lameter (Open Source)
On Thu, 9 Aug 2012, Shuah Khan wrote: > Moving these checks into kmem_cache_sanity_check() would mean return > path handling will change. The first block of sanity checks for name, > and size etc. are done before holding the slab_mutex and the second > block that checks the slab lists is done

Re: [PATCH v2] mm: Restructure kmem_cache_create() to move debug cache integrity checks into a new function

2012-08-09 Thread Christoph Lameter (Open Source)
On Mon, 6 Aug 2012, Shuah Khan wrote: > +#ifdef CONFIG_DEBUG_VM > +static int kmem_cache_sanity_check(const char *name, size_t size) Why do we pass "size" in? AFAICT there is no need to. > @@ -53,48 +93,17 @@ struct kmem_cache *kmem_cache_create(const char *name, > size_t size, size_t align >

Re: [RFC PATCH] mm: introduce N_LRU_MEMORY to distinguish between normal and movable memory

2012-08-09 Thread Christoph Lameter (Open Source)
On Thu, 9 Aug 2012, Hanjun Guo wrote: > Now, We have node masks for both N_NORMAL_MEMORY and > N_HIGH_MEMORY to distinguish between normal and highmem on platforms such as > x86. > But we still don't have such a mechanism to distinguish between "normal" and > "movable" > memory. What is the

Re: [RFC PATCH] mm: introduce N_LRU_MEMORY to distinguish between normal and movable memory

2012-08-09 Thread Christoph Lameter (Open Source)
On Thu, 9 Aug 2012, Hanjun Guo wrote: Now, We have node masks for both N_NORMAL_MEMORY and N_HIGH_MEMORY to distinguish between normal and highmem on platforms such as x86. But we still don't have such a mechanism to distinguish between normal and movable memory. What is the exact

Re: [PATCH v2] mm: Restructure kmem_cache_create() to move debug cache integrity checks into a new function

2012-08-09 Thread Christoph Lameter (Open Source)
On Mon, 6 Aug 2012, Shuah Khan wrote: +#ifdef CONFIG_DEBUG_VM +static int kmem_cache_sanity_check(const char *name, size_t size) Why do we pass size in? AFAICT there is no need to. @@ -53,48 +93,17 @@ struct kmem_cache *kmem_cache_create(const char *name, size_t size, size_t align {

Re: [PATCH v2] mm: Restructure kmem_cache_create() to move debug cache integrity checks into a new function

2012-08-09 Thread Christoph Lameter (Open Source)
On Thu, 9 Aug 2012, Shuah Khan wrote: Moving these checks into kmem_cache_sanity_check() would mean return path handling will change. The first block of sanity checks for name, and size etc. are done before holding the slab_mutex and the second block that checks the slab lists is done after

Re: [PATCH RESEND] mm: Restructure kmem_cache_create() to move debug cache integrity checks into a new function

2012-08-08 Thread Christoph Lameter (Open Source)
On Mon, 6 Aug 2012, Shuah Khan wrote: > No reason, just something I am used to doing :) inline is a good idea. I > can fix that easily and send v2 patch. Leave that to the compiler. There is no performance reason that would give a benefit from forcing inline. -- To unsubscribe from this list:

Re: [PATCH RESEND] mm: Restructure kmem_cache_create() to move debug cache integrity checks into a new function

2012-08-08 Thread Christoph Lameter (Open Source)
On Mon, 6 Aug 2012, Shuah Khan wrote: No reason, just something I am used to doing :) inline is a good idea. I can fix that easily and send v2 patch. Leave that to the compiler. There is no performance reason that would give a benefit from forcing inline. -- To unsubscribe from this list: