2002-03-27 19:39:45

by Eric Sandeen

[permalink] [raw]
Subject: [RFC] kmem_cache_zalloc

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
[email protected] SGI, Inc.


2002-03-27 19:49:17

by Andrew Morton

[permalink] [raw]
Subject: Re: [RFC] kmem_cache_zalloc

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.

-

2002-03-27 19:55:27

by Tigran Aivazian

[permalink] [raw]
Subject: Re: [RFC] kmem_cache_zalloc

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

2002-03-27 20:01:40

by Alan

[permalink] [raw]
Subject: Re: [RFC] kmem_cache_zalloc

> 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

2002-03-27 20:19:49

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [RFC] kmem_cache_zalloc

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

2002-03-27 20:24:59

by Jeff Garzik

[permalink] [raw]
Subject: Re: [RFC] kmem_cache_zalloc

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

Jeff




2002-03-28 11:20:40

by Dipankar Sarma

[permalink] [raw]
Subject: Re: [RFC] kmem_cache_zalloc


In article <[email protected]> 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 <[email protected]> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.

2002-03-28 11:25:41

by David Woodhouse

[permalink] [raw]
Subject: Re: [RFC] kmem_cache_zalloc



[email protected] 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


2002-03-28 11:37:47

by Dipankar Sarma

[permalink] [raw]
Subject: Re: [RFC] kmem_cache_zalloc

On Thu, Mar 28, 2002 at 11:25:12AM +0000, David Woodhouse wrote:
>
>
> [email protected] 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 <[email protected]> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.

2002-03-29 23:00:42

by Pavel Machek

[permalink] [raw]
Subject: Re: [RFC] kmem_cache_zalloc

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

2002-03-29 23:05:01

by Alan

[permalink] [raw]
Subject: Re: [RFC] kmem_cache_zalloc

> > 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.