[RFC] kmem_cache_zalloc

[RFC] kmem_cache_zalloc

[Eric Sandeen]

In the interest of whittling down the changes that XFS makes to the core
kernel, I thought I'd start throwing out some the easier self-contained
modifications for discussion.

XFS adds a kmem_cache_zalloc function to mm/slab.c, it does what you
might expect:  kmem_cache_alloc + memset

Is this something that might be considered for inclusion in the core
kernel, or should we roll it back into fs/xfs?

Thanks,

-Eric

--- 18.1/mm/slab.c Fri, 07 Dec 2001 09:35:49 +1100 kaos (linux-2.4/j/5_slab.c 1.2.1.2.1.2.1.3.1.3 644)
+++ 18.11/mm/slab.c Mon, 07 Jan 2002 13:27:25 +1100 kaos (linux-2.4/j/5_slab.c 1.2.1.2.1.7 644)
@@ -1567,6 +1567,23 @@ void kmem_cache_free (kmem_cache_t *cach
 	local_irq_restore(flags);
 }
 
+void *
+kmem_cache_zalloc(kmem_cache_t *cachep, int flags)
+{
+	void    *ptr;
+	ptr = __kmem_cache_alloc(cachep, flags);
+	if (ptr)
+#if DEBUG
+		memset(ptr, 0, cachep->objsize -
+			(cachep->flags & SLAB_RED_ZONE ? 2*BYTES_PER_WORD : 0));
+#else
+		memset(ptr, 0, cachep->objsize);
+#endif
+
+	return ptr;
+}
+
+


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

Re: [RFC] kmem_cache_zalloc

[Andrew Morton]

Eric Sandeen wrote:
> 
> In the interest of whittling down the changes that XFS makes to the core
> kernel, I thought I'd start throwing out some the easier self-contained
> modifications for discussion.
> 
> XFS adds a kmem_cache_zalloc function to mm/slab.c, it does what you
> might expect:  kmem_cache_alloc + memset
> 
> Is this something that might be considered for inclusion in the core
> kernel, or should we roll it back into fs/xfs?

Count me in.  Clearly a very sane thing to do.

Needs an EXPORT_SYMBOL though.

-

Re: [RFC] kmem_cache_zalloc

[Tigran Aivazian]

On 27 Mar 2002, Eric Sandeen wrote:
> XFS adds a kmem_cache_zalloc function to mm/slab.c, it does what you
> might expect:  kmem_cache_alloc + memset

Useful. However, when I suggested, similarly, a kzalloc() to match
kmalloc() people loudly objected that "it is non-standard" (as if kmalloc
was "standard" in some sense :)
I wonder if they (I can't remember who it was) will say
"kmem_cache_zalloc is a non-standard name"...

Regards,
Tigran

Re: [RFC] kmem_cache_zalloc

[Alan Cox]

> was "standard" in some sense :)
> I wonder if they (I can't remember who it was) will say
> "kmem_cache_zalloc is a non-standard name"...

Much more useful would be kcalloc(). That way we can put all the missing 
32bit overflow checking into kcalloc and remove a lot of crud from the
kernel where we have to keep doing maths checks.

Alan

Re: [RFC] kmem_cache_zalloc

[Christoph Hellwig]

On Wed, Mar 27, 2002 at 01:39:17PM -0600, Eric Sandeen wrote:
> In the interest of whittling down the changes that XFS makes to the core
> kernel, I thought I'd start throwing out some the easier self-contained
> modifications for discussion.
> 
> XFS adds a kmem_cache_zalloc function to mm/slab.c, it does what you
> might expect:  kmem_cache_alloc + memset

I'd really go for k(mem_)zalloc, but a kmem_cache_alloc leads people toward
writing bad code.  The purpose of the slab allocator is to allow caching
readily constructed objects, a _zalloc destroys them on alloc.

I think code using kmem_cache_alloc really wants to use kzalloc and instead
of maintaining it's pool.

	Christoph

Re: [RFC] kmem_cache_zalloc

[Jeff Garzik]

...and of course, there are proposals popping up from time to time, that 
talk about doing background zeroing of pages.

    Jeff

Re: [RFC] kmem_cache_zalloc

[Dipankar Sarma]

In article <20020327201917.A23810@phoenix.infradead.org> Christoph Hellwig wrote:

> I'd really go for k(mem_)zalloc, but a kmem_cache_alloc leads people toward
> writing bad code.  The purpose of the slab allocator is to allow caching
> readily constructed objects, a _zalloc destroys them on alloc.

I thought that the life span of an object is between 
kmem_cache_alloc and kmem_cache_free. If you are expecting caching 
beyond this, you may not get correct data. kmem_cache allocator
is supposed to quickly allocate fixed size structures avoiding
the need for frequent splitting and coalescing in the allocator.

Am I missing something here ?

Thanks
-- 
Dipankar Sarma  <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.

Re: [RFC] kmem_cache_zalloc

[David Woodhouse]

dipankar@in.ibm.com said:
>  I thought that the life span of an object is between
> kmem_cache_alloc and kmem_cache_free. If you are expecting caching
> beyond this, you may not get correct data. kmem_cache allocator is
> supposed to quickly allocate fixed size structures avoiding the need
> for frequent splitting and coalescing in the allocator.

> Am I missing something here ?

Yes. Slab objects can be initialised once when a new page is added to the 
slab, and returned to the slab in reusable form so that you don't have the
cost of complete initialisation on each allocation.

So if for example you have a semaphore in your slab object, instead of
initialising it on each kmem_cache_alloc() you do it once when the new pages
are added to the slab. Then you just make sure it's unlocked each time you
free a slab object.

--
dwmw2

Re: [RFC] kmem_cache_zalloc

[Dipankar Sarma]

On Thu, Mar 28, 2002 at 11:25:12AM +0000, David Woodhouse wrote:
> 
> 
> dipankar@in.ibm.com said:
> >  I thought that the life span of an object is between
> > kmem_cache_alloc and kmem_cache_free. If you are expecting caching
> > beyond this, you may not get correct data. kmem_cache allocator is
> > supposed to quickly allocate fixed size structures avoiding the need
> > for frequent splitting and coalescing in the allocator.
> 
> > Am I missing something here ?
> 
> Yes. Slab objects can be initialised once when a new page is added to the 
> slab, and returned to the slab in reusable form so that you don't have the
> cost of complete initialisation on each allocation.
> 
> So if for example you have a semaphore in your slab object, instead of
> initialising it on each kmem_cache_alloc() you do it once when the new pages
> are added to the slab. Then you just make sure it's unlocked each time you
> free a slab object.

Ok. That makes clear why hch thought kmem_cache_alloc() can lead
to people writing bad code.

Thanks
-- 
Dipankar Sarma  <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.

Re: [RFC] kmem_cache_zalloc

[Pavel Machek]

Hi!

> > was "standard" in some sense :)
> > I wonder if they (I can't remember who it was) will say
> > "kmem_cache_zalloc is a non-standard name"...
> 
> Much more useful would be kcalloc(). That way we can put all the missing 
> 32bit overflow checking into kcalloc and remove a lot of crud from the
> kernel where we have to keep doing maths checks.

What should kcalloc do?
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: [RFC] kmem_cache_zalloc

[Alan Cox]

> > Much more useful would be kcalloc(). That way we can put all the missing 
> > 32bit overflow checking into kcalloc and remove a lot of crud from the
> > kernel where we have to keep doing maths checks.
> 
> What should kcalloc do?

The same as calloc in standard C, but also make sure it does overflow checking.