Re: [patch][rfc] acpi: do not use kmem caches

[Len Brown <lenb@kernel.org>]

On Mon, 1 Dec 2008, Nick Piggin wrote:

> If there is good reason to keep them around, I'm fine with that.
> I think Pekka's suggestion of not doing unions but have better
> typing in the code and then allocate the smaller types from
> kmalloc sounds like a good idea.

Yes, I'll take that up with Bob when he comes back from break.
Maybe the ACPICA code can be improved here.

> If the individual kmem caches are here to stay, then the
> kmem_cache_shrink call should go away. Either way we can delete
> some code from slab.

I think they are here to stay.  We are running
an interpreter in kernel-space with arbitrary input,
so I think the ability to easily isolate run-time memory leaks
on a non-debug system is important.

You may hardly ever see the interpreter run on systems
with few run-time ACPI features, but it runs quite routinely
on many systems.

That said, we have not discovered a memory leak
in a very long time...


BTW.
I question that SLUB combining caches is a good idea.
It seems to fly in the face of how zone allocators
avoid fragmentation -- assuming that "like size"
equates to "like use".

But more important to me is that it reduces visibility.

> The OS agnostic code that implements its own allocator is kind
> of a hack -- I don't understand why you would turn on allocator
> debugging and then circumvent it because you find it too slow.
> But I will never maintain that so if it is compiled out for
> Linux, then OK.

The ACPI interpreter also builds into a user-space simulator
and a debugger.  It is extremely valuable for us to be able
to run the same code in the kernel and also in a user-space
test environment.  So there are a number of features in
the interpreter that we shut off when we build into the
Linux kernel.  Sometimes shutting them off is elegant,
sometime it is clumzy.

"Slabs can take a non-trivial amount of memory.
 On bigger machines it can be many megabytes."

I don't think this thread addressed this concern.
Is it something we should follow-up on?

thanks,
Len Brown, Intel Open Source Technology Center

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>