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

[Nick Piggin <npiggin@suse.de>]

On Mon, Dec 01, 2008 at 07:45:14PM +0300, Alexey Starikovskiy wrote:
> Nick Piggin wrote:
> >On Mon, Dec 01, 2008 at 05:02:50PM +0300, Alexey Starikovskiy wrote:
> >  
> >>Because SLAB has standard memory wells of 2^x size. None of cached ACPI
> >>objects has exactly this size, so bigger block will be used. Plus, 
> >>internal ACPICA caching will add some overhead.
> >>    
> >
> >That's an insane looking caching thing now that I come to closely read
> >the code. There is so much stuff there that I thought it must have been
> >doing something useful which is why I didn't replace the Linux functions
> >with kmalloc/kfree directly.
> >
> >There is really some operating system you support that has such a poor
> >allocator that you think ACPI can do better in 300 lines of code? Why
> >not just rip that whole thing out?
> >  
> You would laugh, this is due to Windows userspace debug library -- it 
> checks for
> memory leaks by default, and it takes ages to do this.

OK... circumvent the debug library? :) I won't argue. But I agree it is
wrong for Linux so my patch is not good. It needs to use kmalloc at least.


> And ACPICA maintainer is sitting on Windows, so he _cares_.
> >>Do you have another interpreter in kernel space?
> >>    
> >
> >So what makes it special?
> >
> >  
> You don't know what size of program you will end up with.
> DSDT could be almost empty, or you could have several thousand of SSDT 
> tables.

OK. And I guess the sizes of the objects seem to be variable as well.
I still think kmalloc would be fine, and would save memory in some
situations. On tiny systems it is less likely to because each slab
costs less memory.

On a big system, the caches can take some MB each in some configurations.

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