Looking at acobject.h, we've never really optimized the operand object for the 64-bit case. There is clearly wasted space in each object due to 64-bit pointer alignment.
I'll take a look at this, the challenge being to optimize both the 32-bit and 64-bit cases in a simple and clear way. Bob > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:linux-acpi- > [EMAIL PROTECTED] On Behalf Of Moore, Robert > Sent: Thursday, March 09, 2006 1:30 PM > To: Brown, Len; [email protected] > Subject: RE: ACPI slab stats > > This object has *already* been split (several times). > > One reason for its very existence is to decrease the size of the > namespace node. Some of the very large objects (such as the Region > objects) were split into yet another sub-object. > > Most namespace objects (not all) require an additional sub-object and > this is the acpi-operand object. We have paid careful attention to > keeping these commonly used (namespace node and operand objects) objects > as small as possible. We use the union to simplify caching of these > objects. > > It might be possible to shrink the two 72-byte objects to 64, keeping > the 64-bit version of the operand object at 64 bytes. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:linux-acpi- > > [EMAIL PROTECTED] On Behalf Of Brown, Len > > Sent: Wednesday, March 08, 2006 10:00 PM > > To: [email protected] > > Subject: Re: ACPI slab stats > > > > 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 > - > 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 - 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
