ACPI slab stats

ACPI slab stats

[Len Brown]

FYI, ACPI slab usage on Viro's box.

1344 * 96 bytes = 129KB, which is significant.

[02:40] <viro> acpi_operand: ffffffff801d90af <acpi_os_acquire_object+b/3e> 1344
[02:40] <viro> size-2048: ffffffff802180fc <acpi_thermal_add+6b/223> 1
[02:40] <viro> size-1024: ffffffff80213331 <acpi_processor_add+65/10a> 1
[02:41] <viro> size-1024: ffffffff8021a01e <acpi_add_single_object+7b/22e> 56
[02:41] <viro> size-512: ffffffff801ff0f8 <acpi_ut_callocate+57/d3> 4
[02:41] <viro> size-192: ffffffff801ff0f8 <acpi_ut_callocate+57/d3> 5
[02:41] <viro> size-32: ffffffff801d8a0c <acpi_os_create_lock+31/c9> 1
[02:41] <viro> size-32: ffffffff801d96ad <acpi_evaluate_integer+8e/2b0> 6
[02:41] <viro> size-32: ffffffff80208071 <acpi_button_add+6b/3a3> 2
[02:41] <viro> size-32: ffffffff8020a85a <acpi_fan_add+74/18f> 1
[02:41] <viro> size-32: ffffffff80210968 <acpi_pci_bind+f1/480> 4
[02:42] <viro> size-32: ffffffff80211008 <acpi_pci_bind_root+f6/246> 1
[02:42] <viro> size-128: ffffffff801ff0f8 <acpi_ut_callocate+57/d3> 801
[02:42] <viro> size-64: ffffffff801d8b4d <acpi_os_create_semaphore+32/124> 15
[02:42] <viro> size-64: ffffffff801ff0f8 <acpi_ut_callocate+57/d3> 13
[02:42] <viro> size-64: ffffffff801ff18a <acpi_ut_create_list+16/40> 2
[02:42] <viro> size-64: ffffffff8020dcf7 <acpi_pci_root_add+80/429> 1
[02:42] <viro> size-64: ffffffff8020f2ae <acpi_pci_link_add+72/26d> 12
[02:43] <viro> size-64: ffffffff8020f8c0 <acpi_pci_irq_add_entry+75/1ae> 40
[02:43] <viro> size-64: ffffffff8021a0f3 <acpi_add_single_object+150/22e> 1

Re: ACPI slab stats

[Brown, Len]

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

RE: ACPI slab stats

[Moore, Robert]

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: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Brown, Len
> Sent: Wednesday, March 08, 2006 10:00 PM
> To: linux-acpi@vger.kernel.org
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: ACPI slab stats

[Moore, Robert]

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: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Moore, Robert
> Sent: Thursday, March 09, 2006 1:30 PM
> To: Brown, Len; linux-acpi@vger.kernel.org
> 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: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> > owner@vger.kernel.org] On Behalf Of Brown, Len
> > Sent: Wednesday, March 08, 2006 10:00 PM
> > To: linux-acpi@vger.kernel.org
> > 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 majordomo@vger.kernel.org
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html