lkml.org 
[lkml]   [2012]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] slab: Ignore internal flags in cache creation
On 09/28/2012 02:56 AM, David Rientjes wrote:
> On Thu, 27 Sep 2012, Glauber Costa wrote:
>
>> But I still don't see the big reason for your objection. If other
>> allocator start using those bits, they would not be passed to
>> kmem_cache_alloc anyway, right? So what would be the big problem in
>> masking them out before it?
>>
>
> A slab allocator implementation may allow for additional bits that are
> currently not used or used for internal purposes by the current set of
> slab allocators to be passed in the unsigned long to kmem_cache_create()
> that would be a no-op on other allocators. It's implementation defined,
> so this masking should be done in the implementation, i.e.
> __kmem_cache_create().
>
> For context, as many people who attended the kernel summit and LinuxCon
> are aware, a new slab allocator is going to be proposed soon that actually
> uses additional bits that aren't defined for all slab allocators. My
> opinion is that leaving unused bits and reserved bits to the
> implementation is the best software engineering practice.
>

I am happy as long as we don't BUG and can mask out that feature.
If Christoph is happy with me masking it in the SLAB only, I'm also fine.


\
 
 \ /
  Last update: 2012-09-28 10:41    [W:8.496 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site