On Mon, Dec 01, 2008 at 12:53:04PM -0500, Len Brown wrote: > > > Or at least stop arguing and throwing bureaucratic stones in the way of > > those wanting to sort out this mess. > > I think we all would be better served if there were more facts > and fewer insults on this thread, can we do that please? > > I do not think the extra work we need to do for ACPICA changes > are a significant hurdle here. We will do what is best for Linux -- > which is what we though we were doing when we changed ACPICA > so Linux could use native caching in the first place. > > The only question that should be on the table here is how > to make Linux be the best it can be. 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. 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. 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. -- 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
