Re: why do we have kfree_s() at all?

From: Horst von Brand (vonbrand@sleipnir.valparaiso.cl)
Date: Wed May 03 2000 - 20:26:23 EST


Mark Hemment <markhe@nextd.demon.co.uk> said:
> > So, why not go through the entire kernel sources and eliminate all uses of
> > kfree_s(), replacing it with kfree() - making the whole thing a little bit
> > faster? I see apm and some sound drivers are using kfree_s()..

> Eh, no!
>
> kfree_s() is there for two reasons;
> o It was there in the previous allocator (before slab allocator).

Not a good reason at all...

> o It does allow that extra check.

It allows people to feed it wrong data and get into trouble, you mean?

> If I had my way, _all_ occurances of kfree() would be replaced with
> kfree_s(). There would be a lot of resistance to this as every consumer
> would need to know/maintain the size of their allocations. That would
> make developers think a bit more about their code (good point), but (in
> some cases) would require an extra field in structures to remember the
> size (bad point).

Please don't! Kernel programming is hard enough as it is, forcing people to
manage an extra datum will just invite mistakes, and thus hard to track
down bugs. Let the machine keep track of clerical details.

[...]

> I've been playing with a new allocation interface, which would extend
> the current interface, for use by high frequency allocations;
> kmem_cookie_t cookie;
> void *objp;
>
> cookie = kmalloc_cookie(1024);
> objp = K_COOKIE_TO_MEM(cookie);
> ...
> kfree_cookie(cookie);
>
> where K_COOKIE_TO_MEM() is simply a macro.

This is _awful_. Why can't the pointer itself serve as the cookie? People
_will_ get this wrong all the time!
       
> Why would this be (much) faster?

Is this really relevant to the kernel's performance? What % of kernel time
does kmalloc()/kfree() consume now? How much would it shave off this?

-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viņa del Mar, Chile                               +56 32 672616

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



This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:13 EST