Re: [PATCH] slab: introduce kmem_cache_zalloc allocator

["Balbir Singh" <balbir@in.ibm.com>]

> No, no, no! I am introducing kmem_cache_zalloc() because there are
> existing users in the tree. I plan to kill the slab wrappers from XFS
> completely which is why I need this. We already have object constructors
> for what you're describing.

Ok, please keep the interface - build kmem_cache_zalloc() on top of
what I suggest.

>
> On Mon, 2006-03-20 at 21:35 +0530, Balbir Singh wrote:
> > This could be used to poison allocated memory. Passing 0 would make
> > this equivalent to kmem_cache_zalloc(). Basically, instead of doing
>
> I am not sure I understand what you mean. We already have slab poisoning
> and that's in mm/slab.c. Why would you want to make the callers aware of
> that?
>

 Basically I am not asking for poisoning support as described by
slab.c. I am talking about general poisoining. Let me try and further
clarify with an example.

Lets say I have a structure resp that is allocated on heap. It is a
part of a response structure for a device (say 1394) and is returned
by the device to the driver.

When I allocate the structure - I would like to do

kmem_cache_alloc_set(&resp, GFP_XXXXX, 0xEE)

The device should ideally fill all fields of resp. Fields that look
0xEE after receiving the response -- would indicate that they were not
filled by the device. This would be extremely useful in debugging.
With kmem_cache_zalloc() - 0 is usually almost always a valid value.
It is useful in some cases and no so much in other cases.

I could easily achieve the same thing by doing a

memset(&resp, 0xEE, size)

after the kmem_cache_alloc(). But since there is an API to zero out
allocated memory, I thought we could make it more generic and more
useful.

Lets say we add an API

kmem_cache_alloc_set(cache, flags, byte)
{
    mem = __cache_alloc(...)
    memset(mem, byte, size)
}

we could have

inline kmem_cache_zalloc(cache, flags)
{
   return kmem_cache_alloc_set(cache, flags, 0)
}

Balbir
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/