On Fri, 28 Sep 2012, David Rientjes wrote:
> All of the move to mm/slab_common.c has obviously slowed down posting of
> SLAM and I haven't complained about that once or asked that it not be
> done, I'm simply pointing out an instance here that will conflict later on
> if we go with this patch. Th
On 10/01/2012 11:28 AM, Pekka Enberg wrote:
> Hello,
>
> [ Found this in my @cs.helsinki.fi inbox, grmbl. ]
>
> On Fri, Sep 28, 2012 at 11:39 PM, David Rientjes wrote:
>> The first prototype, SLAM XP1, will be posted in October. I'd simply like
>> to avoid reverting this patch down the road and
Hello,
[ Found this in my @cs.helsinki.fi inbox, grmbl. ]
On Fri, Sep 28, 2012 at 11:39 PM, David Rientjes wrote:
> The first prototype, SLAM XP1, will be posted in October. I'd simply like
> to avoid reverting this patch down the road and having all of us
> reconsider the topic again when clea
On Fri, 28 Sep 2012, Christoph Lameter wrote:
> > The first prototype, SLAM XP1, will be posted in October. I'd simply like
> > to avoid reverting this patch down the road and having all of us
> > reconsider the topic again when clear alternatives exist that, in my
> > opinion, make the code clea
On Fri, 28 Sep 2012, Glauber Costa wrote:
> 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.
>
Absolutely, I agree that the implementation-defined __kmem_cache_create()
can mask out bits that are not us
On Fri, 28 Sep 2012, David Rientjes wrote:
> The first prototype, SLAM XP1, will be posted in October. I'd simply like
> to avoid reverting this patch down the road and having all of us
> reconsider the topic again when clear alternatives exist that, in my
> opinion, make the code cleaner.
If yo
On Fri, 28 Sep 2012, Christoph Lameter wrote:
> > No, it's implementation defined so it shouldn't be in kmem_cache_create(),
> > it should be in __kmem_cache_create()
>
> The flags are standardized between allocators. We carve out a couple of
> bits here that can be slab specific.
>
That's true
On Fri, 28 Sep 2012, Christoph Lameter wrote:
> > 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 lea
On Fri, 28 Sep 2012, Christoph Lameter wrote:
> > > This means touching another field from critical paths of the allocators.
> > > It would increase the cache footprint and therefore reduce performance.
> > >
> >
> > To clarify your statement, you're referring to the mm/slab.c allocation of
> > ne
On Thu, 27 Sep 2012, David Rientjes wrote:
> No, it's implementation defined so it shouldn't be in kmem_cache_create(),
> it should be in __kmem_cache_create()
The flags are standardized between allocators. We carve out a couple of
bits here that can be slab specific.
> > There *are* multiple sl
On Thu, 27 Sep 2012, 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
>
On Thu, 27 Sep 2012, David Rientjes wrote:
> > This means touching another field from critical paths of the allocators.
> > It would increase the cache footprint and therefore reduce performance.
> >
>
> To clarify your statement, you're referring to the mm/slab.c allocation of
> new slab pages an
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
>
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 imp
On Thu, 27 Sep 2012, Christoph Lameter wrote:
> > > > Nack, this is already handled by CREATE_MASK in the mm/slab.c allocator;
> > >
> > > CREATE_MASK defines legal flags that can be specified. Other flags cause
> > > and error. This is about flags that are internal that should be ignored
> > > wh
On Thu, 27 Sep 2012, Christoph Lameter wrote:
> > I would suggest cachep->flags being used solely for the flags passed to
> > kmem_cache_create() and seperating out all "internal flags" based on the
> > individual slab allocator's implementation into a different field. There
> > should be no prob
On Wed, 26 Sep 2012, David Rientjes wrote:
> On Wed, 26 Sep 2012, Christoph Lameter wrote:
>
> > > Nack, this is already handled by CREATE_MASK in the mm/slab.c allocator;
> >
> > CREATE_MASK defines legal flags that can be specified. Other flags cause
> > and error. This is about flags that are i
On Wed, 26 Sep 2012, David Rientjes wrote:
> I would suggest cachep->flags being used solely for the flags passed to
> kmem_cache_create() and seperating out all "internal flags" based on the
> individual slab allocator's implementation into a different field. There
> should be no problem with mo
On 09/27/2012 05:16 AM, David Rientjes wrote:
> On Wed, 26 Sep 2012, Glauber Costa wrote:
>
>> So the problem I am facing here is that when I am creating caches from
>> memcg, I would very much like to reuse their flags fields. They are
>> stored in the cache itself, so this is not a problem. But
On Wed, 26 Sep 2012, Glauber Costa wrote:
> So the problem I am facing here is that when I am creating caches from
> memcg, I would very much like to reuse their flags fields. They are
> stored in the cache itself, so this is not a problem. But slab also
> stores that flag, leading to the precise
On Wed, 26 Sep 2012, Christoph Lameter wrote:
> > Nack, this is already handled by CREATE_MASK in the mm/slab.c allocator;
>
> CREATE_MASK defines legal flags that can be specified. Other flags cause
> and error. This is about flags that are internal that should be ignored
> when specified.
>
T
On Tue, 25 Sep 2012, David Rientjes wrote:
> Nack, this is already handled by CREATE_MASK in the mm/slab.c allocator;
CREATE_MASK defines legal flags that can be specified. Other flags cause
and error. This is about flags that are internal that should be ignored
when specified.
I think it makes
On 09/26/2012 04:46 AM, David Rientjes wrote:
> On Tue, 25 Sep 2012, Christoph Lameter wrote:
>
>>> No cache should ever pass those as a creation flags. We can just ignore
>>> this bit if it happens to be passed (such as when duplicating a cache in
>>> the kmem memcg patches)
>>
>> Acked-by: Chris
On Tue, 25 Sep 2012, Christoph Lameter wrote:
> > No cache should ever pass those as a creation flags. We can just ignore
> > this bit if it happens to be passed (such as when duplicating a cache in
> > the kmem memcg patches)
>
> Acked-by: Christoph Lameter
>
Nack, this is already handled by
On Tue, 25 Sep 2012, Glauber Costa wrote:
> No cache should ever pass those as a creation flags. We can just ignore
> this bit if it happens to be passed (such as when duplicating a cache in
> the kmem memcg patches)
Acked-by: Christoph Lameter
--
To unsubscribe from this list: send the line "un
25 matches
Mail list logo
