These three jump out as worth thinking about:
> [02:40] <viro> acpi_operand: ffffffff801d90af
<acpi_os_acquire_object+b/3e> 1344
/proc/slabinfo on my 64-bit box shows these are 96 bytes each
with CONFIG_DEBUG_SLAB=y, and 72 bytes each for CONFIG_DEBUG_SLAB=n.
1344*72 = 96KB
sizeof(union acpi_operand_object) is 72, but that is significantly
larger than many of its possible members:
union acpi_operand_object 72
struct acpi_object_common 24
struct acpi_object_integer 32
struct acpi_object_string 32
struct acpi_object_buffer 56
struct acpi_object_package 56
struct acpi_object_event 32
struct acpi_object_method 56
struct acpi_object_mutex 72
struct acpi_object_region 64
struct acpi_object_notify_common 48
struct acpi_object_device 56
struct acpi_object_power_resource 56
struct acpi_object_processor 64
struct acpi_object_thermal_zone 48
struct acpi_object_field_common 56
struct acpi_object_region_field 56
struct acpi_object_buffer_field 56
struct acpi_object_bank_field 64
struct acpi_object_index_field 64
struct acpi_object_notify_handler 48
struct acpi_object_addr_handler 72
struct acpi_object_reference 48
struct acpi_object_extra 48
struct acpi_object_data 40
struct acpi_object_cache_list 32
Bob,
is it conceivable to split this union up into multiple types
to beneift from making the smaller uses small?
> [02:42] <viro> size-128: ffffffff801ff0f8 <acpi_ut_callocate+57/d3>
801
801*128 = 102KB
Hmmm, expect this to be from
note sure where these are from. some of the ACPI_MEM_CALLOCATE
sizes are these:
struct acpi_namespace_node 40
struct acpi_walk_state 984
struct acpi_handler_info 24
struct acpi_pci_id 8
struct acpi_device_info 104
struct fadt_descriptor_rev2 244
struct acpi_table_desc 72
> [02:41] <viro> size-1024: ffffffff8021a01e
<acpi_add_single_object+7b/22e> 56
1024 * 56 = 56KB
These are struct acpi_device, which break out like this:
struct acpi_device 960
void * 8
struct acpi_device * 8
struct list_head 16
struct list_head 16
struct list_head 16
struct list_head 16
struct acpi_device_status 4
struct acpi_device_flags 4
struct acpi_device_pnp 112
struct acpi_device_power 424
struct acpi_device_wakeup 120
struct acpi_device_perf 24
struct acpi_device_dir 8
struct acpi_device_ops 88
struct acpi_driver * 8
void * 8
struct kobject 80
here we lose (1024 - 960) = 64 bytes/entry on rounding error
56 * 65 = 3.5 KB of padding
struct acpi_device_power 424:
struct acpi_device_power_flags 4
struct acpi_device_power_state 104
struct acpi_device_power_state 104
struct acpi_device_power_state 104
struct acpi_device_power_state 104
struct acpi_device_power_state 104:
int 4
int 4
struct acpi_handle_list 88
which comes from this:
/* TBD: Make dynamic */
#define ACPI_MAX_HANDLES 10
struct acpi_handle_list {
u32 count;
acpi_handle handles[ACPI_MAX_HANDLES];
};
So 80-bytes can be wrung out of acpi_handle_list,
saving 320/424 bytes of acpi_device_power.
saving 320/960 bytes of acpi_device
gettig it down to 640 bytes -- though with the current
scheme that will still be rounded up to the 1024-byte slab.
volunteers?
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
