J
#define ACPI_PATHNAME_MAX 256 /* A full namespace pathname */ acpi_pci_bind() char pathname[ACPI_PATHNAME_MAX] = {0}; acpi_pci_irq_add_prt() char pathname[ACPI_PATHNAME_MAX] = {0};
Created attachment 3217 [details] a testing patch against 2.6 dynamic alloc memory for pathname , instead of consume stack space
1.This patch can save 512 bytes. 2. disable ACPI_DEBUG_OUTPUT can save sizeof(acpi_debug_print_info) (12 byteSon IA32) for each acpi function, having ACPI_FUNCTION_TRACE. For this cases (on IA32) , there could save 29*12 = 348 Bytes. Totally, we can save 512+348 = 860 byte on stack. Thanks, Luming
224 acpi_get_firmware_table Fixed in ACPI CA version 20040715: Completed a major reduction in CPU stack use for the AcpiGetFirmwareTable external function. In the 32-bit non-debug case, the stack use has been reduced from 168 bytes to 32 bytes.
For 2.6.10-rc2 , run make checkstack | grep acpi got: 0xc0242438 acpi_pci_bind: 304 0xc02427e9 acpi_pci_bind_root: 296 0xc02423b9 acpi_pci_bind: 288 0xc0241b27 acpi_pci_irq_add_prt: 284 0xc0241c2b acpi_pci_irq_add_prt: 284 0xc02426bb acpi_pci_bind_root: 280 0xc024102e acpi_pci_link_set: 212 0xc02410a2 acpi_pci_link_set: 212 0xc023f286 acpi_video_bus_POST_seq_show: 164 0xc0246c05 acpi_thermal_write_trip_points: 156 0xc0246c87 acpi_thermal_write_trip_points: 156 0xc023f210 acpi_video_bus_POST_seq_show: 148 0xc020fef2 acpi_evaluate_reference: 140 0xc0210046 acpi_evaluate_reference: 140 0xc020fd42 acpi_evaluate_integer: 136 0xc020fe32 acpi_evaluate_integer: 136 0xc0228ffc acpi_get_object_info: 120 0xc0229030 acpi_get_object_info: 120 0xc0205ee1 acpi_query_osc: 112 0xc0205fad acpi_query_osc: 112 0xc0206041 acpi_run_osc: 112 0xc020610d acpi_run_osc: 112
Created attachment 4131 [details] an update against 2.6.10-rc2 make checkstack | grep acpi 0xc020fef2 acpi_evaluate_reference: 140 0xc0210046 acpi_evaluate_reference: 140 0xc020fd42 acpi_evaluate_integer: 136 0xc020fe32 acpi_evaluate_integer: 136 0xc0228ffc acpi_get_object_info: 120 0xc0229030 acpi_get_object_info: 120 0xc0205ee1 acpi_query_osc: 112 0xc0205fad acpi_query_osc: 112 0xc0206041 acpi_run_osc: 112 0xc020610d acpi_run_osc: 112
Created attachment 4132 [details] a update version against 2.6.10-rc1
Created attachment 4186 [details] an update version against latest acpi tree
applied patch in comment #8 to acpi-test tree
assigning to Bob to take a look at the remaining routines.
Created attachment 4297 [details] incremental clean-up patch applied
Created attachment 4298 [details] another incremental cleanup patch applied
Created attachment 4299 [details] remove the first hunk Just remove the fist hunk.
Created attachment 4300 [details] stack audit for acpi_pci_unbind and acpi_evaluate_integer. [root@titan2 testing]# diff z z1 1,8c1,6 < 0xc020cd21 acpi_pci_unbind: 300 < 0xc020cbee acpi_pci_unbind: 284 < 0xc01e3393 acpi_evaluate_reference: 140 < 0xc01e36e0 acpi_evaluate_reference: 140 < 0xc01e31ee acpi_evaluate_integer: 136 < 0xc01e3384 acpi_evaluate_integer: 136 < 0xc01fa6ac acpi_get_object_info: 120 < 0xc01fa88f acpi_get_object_info: 120 --- > 0xc01e3401 acpi_evaluate_reference: 140 > 0xc01e374e acpi_evaluate_reference: 140 > 0xc01e31f0 acpi_evaluate_integer: 124 > 0xc01e33f5 acpi_evaluate_integer: 124 > 0xc01fa71c acpi_get_object_info: 120 > 0xc01fa8ff acpi_get_object_info: 120
I don't know why acpi_evaluate_reference and acpi_evaluate_integer consumes stack above 100. BTW,acpi_get_object_info is belong to acpi ca.
$ objdump -d vmlinux > out $ vi out /acpi_evaluate_integer c0214edd <acpi_evaluate_integer>: c0214edd: 55 push %ebp c0214ede: 57 push %edi c0214edf: 56 push %esi c0214ee0: 53 push %ebx c0214ee1: 83 ec 7c sub $0x7c,%esp 0x7c = 124 -- so checkstack.pl is taking it from vmlinux correctly. Not immediately clear from the assembly, however, why gcc created so much stack space in this function. --- after patch in comment #14 applied: 0x000036f4 acpi_processor_write_performance: 268 0x0000353a acpi_processor_write_performance: 252 is new (why two values?) 0xc0261309 hpet_acpi_add: 144 0xc0261361 hpet_acpi_add: 144 0xc0261379 hpet_acpi_add: 144 0xc02150e0 acpi_evaluate_reference: 136 0xc0215415 acpi_evaluate_reference: 136 why on list? 0xc0214ee1 acpi_evaluate_integer: 124 0xc02150d4 acpi_evaluate_integer: 124 why on list? 0x0000174f acpi_processor_get_power_info_cst: 124 0x00001a5e acpi_processor_get_power_info_cst: 124 is new. 0xc022c217 acpi_get_object_info: 120 0xc022c3d6 acpi_get_object_info: 120 yes, this one is ACPICA.
after actually re-building vmlinux so that checkstack.pl will get the right answer, we're left with these: 0x00001fbd acpi_processor_write_performance: 236 0x000020e3 acpi_processor_write_performance: 236 0xc024eaa9 hpet_acpi_add: 144 0xc024eb01 hpet_acpi_add: 144 0xc024eb19 hpet_acpi_add: 144 0xc0221e0a acpi_get_object_info: 120 0xc0221fba acpi_get_object_info: 120 0x00000e0b acpi_processor_get_power_info_cst: 104 0x00001027 acpi_processor_get_power_info_cst: 104
Looking at kernel 2.6.13-rc3-mm1, there don't seem to be any real stack usage problem, especially regarding the call path J