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 from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
