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