Bug 2901 - stack consumption audit
Summary: stack consumption audit
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Other (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: Luming Yu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-16 19:08 UTC by Len Brown
Modified: 2005-08-18 08:20 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6
Tree: Mainline
Regression: ---


Attachments
a testing patch against 2.6 (3.63 KB, patch)
2004-06-22 02:03 UTC, Luming Yu
Details | Diff
an update against 2.6.10-rc2 (11.15 KB, patch)
2004-11-24 02:27 UTC, Luming Yu
Details | Diff
a update version against 2.6.10-rc1 (11.20 KB, patch)
2004-11-24 04:03 UTC, Luming Yu
Details | Diff
an update version against latest acpi tree (10.81 KB, patch)
2004-12-01 06:04 UTC, Luming Yu
Details | Diff
incremental clean-up patch applied (1.30 KB, patch)
2004-12-23 11:40 UTC, Len Brown
Details | Diff
another incremental cleanup patch applied (1.28 KB, patch)
2004-12-23 20:06 UTC, Len Brown
Details | Diff
remove the first hunk (439 bytes, patch)
2004-12-23 21:42 UTC, Luming Yu
Details | Diff
stack audit for acpi_pci_unbind and acpi_evaluate_integer. (2.62 KB, patch)
2004-12-23 21:47 UTC, Luming Yu
Details | Diff

Description Len Brown 2004-06-16 19:08:29 UTC
J
Comment 1 Len Brown 2004-06-17 14:13:07 UTC
#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}; 
 
Comment 2 Luming Yu 2004-06-22 02:03:57 UTC
Created attachment 3217 [details]
a testing patch against 2.6

dynamic alloc memory for pathname , instead of consume stack space
Comment 3 Luming Yu 2004-06-22 02:12:25 UTC
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
Comment 4 Robert Moore 2004-07-23 15:09:41 UTC
     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.

Comment 5 Luming Yu 2004-11-24 02:09:10 UTC
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
Comment 6 Luming Yu 2004-11-24 02:27:56 UTC
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
Comment 7 Luming Yu 2004-11-24 04:03:22 UTC
Created attachment 4132 [details]
a update version against 2.6.10-rc1
Comment 8 Luming Yu 2004-12-01 06:04:35 UTC
Created attachment 4186 [details]
an update version against latest acpi tree
Comment 9 Len Brown 2004-12-05 20:58:11 UTC
applied patch in comment #8 to acpi-test tree 
Comment 10 Len Brown 2004-12-08 18:15:47 UTC
assigning to Bob to take a look at the remaining routines.
Comment 11 Len Brown 2004-12-23 11:40:51 UTC
Created attachment 4297 [details]
incremental clean-up patch applied
Comment 12 Len Brown 2004-12-23 20:06:12 UTC
Created attachment 4298 [details]
another incremental cleanup patch applied
Comment 13 Luming Yu 2004-12-23 21:42:01 UTC
Created attachment 4299 [details]
remove the first hunk

Just remove the fist hunk.
Comment 14 Luming Yu 2004-12-23 21:47:11 UTC
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
Comment 15 Luming Yu 2004-12-23 21:51:00 UTC
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.
Comment 16 Len Brown 2005-01-26 23:06:27 UTC
$ 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. 
Comment 17 Len Brown 2005-01-26 23:41:33 UTC
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 
 
Comment 18 Adrian Bunk 2005-07-22 10:57:31 UTC
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

Note You need to log in before you can comment on or make changes to this bug.