Christoph Hellwig wrote:
On Mon, Dec 01, 2008 at 05:14:36PM +0300, Alexey Starikovskiy wrote:
Why then you try to delete ACPICA code, which might be just disabled by
undefining ACPI_USE_LOCAL_CACHE?
If you do want to go that path, you need to create patch against ACPICA, not
Linux code.
Sorry dude, but that's not how Linux development works. Please talk to
some intel OTC folks to get an advice on how it does.
We are not speaking about Linux code here -- Nick changed ACPICA files.
And he already admits, that his patch is at least half-way wrong.
Sorry dude, ACPICA code is not Linux only, so one needs some care while
dropping some functionality from it.
Ah OK I misread, that's the cache's freelist... ACPI shouldn't be poking
this button inside the slab allocator anyway, honestly. What is it
for?
And it is not actually used -- you cannot unload ACPI interpreter, and
this function is called only from there.
Care to remove all this dead code?
It is used at least in Windows userspace programs. So, removing these 4
lines only from Linux will
create another headache for Len during his merging of each new ACPICA
release into Linux.
Is there a reasonable performance or memory win by using kmem cache? If
not, then they should not be used
ACPI is still working in machines with several megabytes of RAM and
100mhz Pentium processors. Do you say we should just not consider them
any longer?
If so, then just delete all ACPICA caches altogether.
As Nick is trying to explain you for a while it's not actually going
to be a performance benefit for these, quite contrary because of how
slab caches waste a lot of memory when only used very lightly or not
at all.
If you care to do the math, and I helped you in another posting, he may
save about 11k in 32bit mode on thinkpad, and loose 70k in 64bit mode on
similar thinkpad.
Regards,
Alex.
--
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
