ACPICA: Drop Operand cache
RFC PATCH 1/1 ACPICA: Drop Operand cache
Hi,
I've played with AcpiOperandObject union and corresponding cache. Removing the union does not seem to be viable -- patch easily overcomes .5 meg barrier, without any visible change. Dropping only the cache and making all individual objects allocated from heap requires smaller number of changes and chould make SLAB/SLUB developers happy.
Regards,
Alex.
ACPICA: Drop Operand cache
From: Alexey Starikovskiy <[email protected]>
---
source/components/debugger/dbexec.c | 1 source/components/debugger/dbstats.c | 7 - source/components/dispatcher/dsfield.c | 6 - source/components/dispatcher/dsopcode.c | 20 +-- source/components/events/evregion.c | 38 +----- source/components/events/evrgnini.c | 12 -- source/components/executer/excreate.c | 7 - source/components/executer/exprep.c | 6 - source/components/namespace/nsobject.c | 33 ----- source/components/utilities/utalloc.c | 15 -- source/components/utilities/utcopy.c | 2 source/components/utilities/utdelete.c | 38 ------ source/components/utilities/utobject.c | 167 ++++++++++++-------------- source/components/utilities/utxface.c | 1 source/include/acglobal.h | 1 source/include/acnamesp.h | 4 - source/include/acobject.h | 29 +---- source/include/actypes.h | 1 source/include/acutils.h | 2 source/os_specific/service_layers/osunixxf.c | 2 20 files changed, 109 insertions(+), 283 deletions(-)
source/components/debugger/dbexec.c +0 -1
@@ -358,7 +358,6 @@ AcpiDbGetOutstandingAllocations ( Outstanding +=AcpiDbGetCacheInfo (AcpiGbl_StateCache); Outstanding +=AcpiDbGetCacheInfo (AcpiGbl_PsNodeCache); Outstanding +=AcpiDbGetCacheInfo (AcpiGbl_PsNodeExtCache); - Outstanding +=AcpiDbGetCacheInfo (AcpiGbl_OperandCache);#endif return (Outstanding);
source/components/debugger/dbstats.c +1 -6
@@ -306,10 +306,7 @@ AcpiDbEnumerateObject (case ACPI_TYPE_BUFFER_FIELD : -if (AcpiNsGetSecondaryObject (ObjDesc)) - { - AcpiGbl_ObjTypeCount [ACPI_TYPE_BUFFER_FIELD ]++; - } + AcpiGbl_ObjTypeCount [ACPI_TYPE_BUFFER_FIELD ]++;break ;case ACPI_TYPE_REGION :
@@ -531,7 +528,6 @@ AcpiDbDisplayStatistics (#ifdef ACPI_USE_LOCAL_CACHE AcpiOsPrintf ("\n----Cache Statistics (all in hex)---------\n" ); -AcpiDbListInfo (AcpiGbl_OperandCache);AcpiDbListInfo (AcpiGbl_PsNodeCache);AcpiDbListInfo (AcpiGbl_PsNodeExtCache);AcpiDbListInfo (AcpiGbl_StateCache);
@@ -582,7 +578,6 @@ AcpiDbDisplayStatistics (AcpiOsPrintf ("Reference %3d\n" ,sizeof (ACPI_OBJECT_REFERENCE ));AcpiOsPrintf ("Notify %3d\n" ,sizeof (ACPI_OBJECT_NOTIFY_HANDLER ));AcpiOsPrintf ("AddressSpace %3d\n" ,sizeof (ACPI_OBJECT_ADDR_HANDLER )); -AcpiOsPrintf ("Extra %3d\n" ,sizeof (ACPI_OBJECT_EXTRA ));AcpiOsPrintf ("Data %3d\n" ,sizeof (ACPI_OBJECT_DATA ));AcpiOsPrintf ("\n" );
source/components/dispatcher/dsfield.c +2 -4
@@ -164,7 +164,6 @@ AcpiDsCreateBufferField (ACPI_NAMESPACE_NODE *Node;ACPI_STATUS Status;ACPI_OPERAND_OBJECT *ObjDesc; -ACPI_OPERAND_OBJECT *SecondDesc =NULL ;UINT32 Flags;
@@ -266,9 +265,8 @@ AcpiDsCreateBufferField (* Remember location in AML stream of the field unit opcode and operands -- * since the buffer and index operands must be evaluated. */ - SecondDesc = ObjDesc->Common.NextObject; - SecondDesc->Extra.AmlStart = Op->Named.Data; - SecondDesc->Extra.AmlLength = Op->Named.Length; + ObjDesc->BufferField.AmlStart = Op->Named.Data; + ObjDesc->BufferField.AmlLength = Op->Named.Length; ObjDesc->BufferField.Node = Node;/* Attach constructed field descriptors to parent node */
source/components/dispatcher/dsopcode.c +4 -16
@@ -283,7 +283,6 @@ ACPI_STATUSAcpiDsGetBufferFieldArguments ( ACPI_OPERAND_OBJECT *ObjDesc) { -ACPI_OPERAND_OBJECT *ExtraDesc;ACPI_NAMESPACE_NODE *Node;ACPI_STATUS Status;
@@ -298,7 +297,6 @@ AcpiDsGetBufferFieldArguments (/* Get the AML pointer (method object) and BufferField node */ - ExtraDesc =AcpiNsGetSecondaryObject (ObjDesc); Node = ObjDesc->BufferField.Node;ACPI_DEBUG_EXEC (AcpiUtDisplayInitPathname (ACPI_TYPE_BUFFER_FIELD , Node,NULL ));
@@ -308,7 +306,7 @@ AcpiDsGetBufferFieldArguments (/* Execute the AML code for the TermArg arguments */ Status =AcpiDsExecuteArguments (Node,AcpiNsGetParentNode (Node), - ExtraDesc->Extra.AmlLength, ExtraDesc->Extra.AmlStart); + ObjDesc->BufferField.AmlLength, ObjDesc->BufferField.AmlStart);return_ACPI_STATUS (Status); }
@@ -330,7 +328,6 @@ ACPI_STATUSAcpiDsGetBankFieldArguments ( ACPI_OPERAND_OBJECT *ObjDesc) { -ACPI_OPERAND_OBJECT *ExtraDesc;ACPI_NAMESPACE_NODE *Node;ACPI_STATUS Status;
@@ -345,7 +342,6 @@ AcpiDsGetBankFieldArguments (/* Get the AML pointer (method object) and BankField node */ - ExtraDesc =AcpiNsGetSecondaryObject (ObjDesc); Node = ObjDesc->BankField.Node;ACPI_DEBUG_EXEC (AcpiUtDisplayInitPathname (ACPI_TYPE_LOCAL_BANK_FIELD , Node,NULL ));
@@ -355,7 +351,7 @@ AcpiDsGetBankFieldArguments (/* Execute the AML code for the TermArg arguments */ Status =AcpiDsExecuteArguments (Node,AcpiNsGetParentNode (Node), - ExtraDesc->Extra.AmlLength, ExtraDesc->Extra.AmlStart); + ObjDesc->BankField.AmlLength, ObjDesc->BankField.AmlStart);return_ACPI_STATUS (Status); }
@@ -477,8 +473,6 @@ AcpiDsGetRegionArguments ( {ACPI_NAMESPACE_NODE *Node;ACPI_STATUS Status; -ACPI_OPERAND_OBJECT *ExtraDesc; -ACPI_FUNCTION_TRACE_PTR (DsGetRegionArguments, ObjDesc);
@@ -488,12 +482,6 @@ AcpiDsGetRegionArguments (return_ACPI_STATUS (AE_OK ); } - ExtraDesc =AcpiNsGetSecondaryObject (ObjDesc); -if (!ExtraDesc) - { -return_ACPI_STATUS (AE_NOT_EXIST ); - } -/* Get the Region node */ Node = ObjDesc->Region.Node;
@@ -501,12 +489,12 @@ AcpiDsGetRegionArguments (ACPI_DEBUG_EXEC (AcpiUtDisplayInitPathname (ACPI_TYPE_REGION , Node,NULL ));ACPI_DEBUG_PRINT ((ACPI_DB_EXEC ,"[%4.4s] OpRegion Arg Init at AML %p\n" , -AcpiUtGetNodeName (Node), ExtraDesc->Extra.AmlStart)); +AcpiUtGetNodeName (Node), ObjDesc->Region.AmlStart));/* Execute the argument AML */ Status =AcpiDsExecuteArguments (Node,AcpiNsGetParentNode (Node), - ExtraDesc->Extra.AmlLength, ExtraDesc->Extra.AmlStart); + ObjDesc->Region.AmlLength, ObjDesc->Region.AmlStart);return_ACPI_STATUS (Status); }
source/components/events/evregion.c +6 -32
@@ -298,20 +298,13 @@ AcpiEvExecuteRegMethod ( {ACPI_EVALUATE_INFO *Info;ACPI_OPERAND_OBJECT *Args[3 ]; -ACPI_OPERAND_OBJECT *RegionObj2;ACPI_STATUS Status;ACPI_FUNCTION_TRACE (EvExecuteRegMethod); - RegionObj2 =AcpiNsGetSecondaryObject (RegionObj); -if (!RegionObj2) - { -return_ACPI_STATUS (AE_NOT_EXIST ); - } - -if (RegionObj2->Extra.Method_REG ==NULL ) +if (RegionObj->Region.Method_REG ==NULL ) {return_ACPI_STATUS (AE_OK ); }
@@ -324,7 +317,7 @@ AcpiEvExecuteRegMethod (return_ACPI_STATUS (AE_NO_MEMORY ); } - Info->PrefixNode = RegionObj2->Extra.Method_REG; + Info->PrefixNode = RegionObj->Region.Method_REG; Info->Pathname =NULL ; Info->Parameters = Args; Info->Flags =ACPI_IGNORE_RETURN_VALUE ;
@@ -406,19 +399,10 @@ AcpiEvAddressSpaceDispatch (ACPI_ADR_SPACE_HANDLER Handler;ACPI_ADR_SPACE_SETUP RegionSetup;ACPI_OPERAND_OBJECT *HandlerDesc; -ACPI_OPERAND_OBJECT *RegionObj2;void *RegionContext =NULL ; -ACPI_FUNCTION_TRACE (EvAddressSpaceDispatch); - - RegionObj2 =AcpiNsGetSecondaryObject (RegionObj); -if (!RegionObj2) - { -return_ACPI_STATUS (AE_NOT_EXIST ); - } -/* Ensure that there is a handler associated with this region */ HandlerDesc = RegionObj->Region.Handler;
@@ -481,7 +465,7 @@ AcpiEvAddressSpaceDispatch ( { RegionObj->Region.Flags |=AOPOBJ_SETUP_COMPLETE ; -if (RegionObj2->Extra.RegionContext) +if (RegionObj->Region.RegionContext) {/* The handler for this region was already installed */
@@ -493,7 +477,7 @@ AcpiEvAddressSpaceDispatch (* Save the returned context for use in all accesses to * this particular region */ - RegionObj2->Extra.RegionContext = RegionContext; + RegionObj->Region.RegionContext = RegionContext; } } }
@@ -522,7 +506,7 @@ AcpiEvAddressSpaceDispatch (/* Call the handler */ Status =Handler (Function, Address, BitWidth, Value, - HandlerDesc->AddressSpace.Context, RegionObj2->Extra.RegionContext); + HandlerDesc->AddressSpace.Context, RegionObj->Region.RegionContext);if (ACPI_FAILURE (Status)) {
@@ -568,19 +552,13 @@ AcpiEvDetachRegion(ACPI_OPERAND_OBJECT **LastObjPtr;ACPI_ADR_SPACE_SETUP RegionSetup;void **RegionContext; -ACPI_OPERAND_OBJECT *RegionObj2;ACPI_STATUS Status;ACPI_FUNCTION_TRACE (EvDetachRegion); - RegionObj2 =AcpiNsGetSecondaryObject (RegionObj); -if (!RegionObj2) - { - return_VOID; - } - RegionContext = &RegionObj2->Extra.RegionContext; + RegionContext = &RegionObj->Region.RegionContext;/* Get the address handler from the region object */
@@ -1042,10 +1020,6 @@ AcpiEvInstallSpaceHandler ( goto UnlockAndExit; } -/* Init new descriptor */ - - ObjDesc->Common.Type = (UINT8 ) Type; -/* Attach the new object to the Node */ Status =AcpiNsAttachObject (Node, ObjDesc, Type);
source/components/events/evrgnini.c +2 -10
@@ -675,8 +675,6 @@ AcpiEvInitializeRegion (ACPI_STATUS Status;ACPI_NAMESPACE_NODE *MethodNode;ACPI_NAME *RegNamePtr = (ACPI_NAME *)METHOD_NAME__REG ; -ACPI_OPERAND_OBJECT *RegionObj2; -ACPI_FUNCTION_TRACE_U32 (EvInitializeRegion, AcpiNsLocked);
@@ -691,19 +689,13 @@ AcpiEvInitializeRegion (return_ACPI_STATUS (AE_OK ); } - RegionObj2 =AcpiNsGetSecondaryObject (RegionObj); -if (!RegionObj2) - { -return_ACPI_STATUS (AE_NOT_EXIST ); - } - Node =AcpiNsGetParentNode (RegionObj->Region.Node); SpaceId = RegionObj->Region.SpaceId;/* Setup defaults */ RegionObj->Region.Handler =NULL ; - RegionObj2->Extra.Method_REG =NULL ; + RegionObj->Region.Method_REG =NULL ; RegionObj->Common.Flags &= ~(AOPOBJ_SETUP_COMPLETE ); RegionObj->Common.Flags |=AOPOBJ_OBJECT_INITIALIZED ;
@@ -718,7 +710,7 @@ AcpiEvInitializeRegion (* definition. This will be executed when the handler is attached * or removed */ - RegionObj2->Extra.Method_REG = MethodNode; + RegionObj->Region.Method_REG = MethodNode; }/*
source/components/executer/excreate.c +2 -5
@@ -376,8 +376,6 @@ AcpiExCreateRegion (ACPI_STATUS Status;ACPI_OPERAND_OBJECT *ObjDesc;ACPI_NAMESPACE_NODE *Node; -ACPI_OPERAND_OBJECT *RegionObj2; -ACPI_FUNCTION_TRACE (ExCreateRegion);
@@ -422,9 +420,8 @@ AcpiExCreateRegion (* Remember location in AML stream of address & length * operands since they need to be evaluated at run time. */ - RegionObj2 = ObjDesc->Common.NextObject; - RegionObj2->Extra.AmlStart = AmlStart; - RegionObj2->Extra.AmlLength = AmlLength; + ObjDesc->Region.AmlStart = AmlStart; + ObjDesc->Region.AmlLength = AmlLength;/* Init the region from the operands */
source/components/executer/exprep.c +2 -4
@@ -511,7 +511,6 @@ AcpiExPrepFieldValue ( ACPI_CREATE_FIELD_INFO *Info) {ACPI_OPERAND_OBJECT *ObjDesc; -ACPI_OPERAND_OBJECT *SecondDesc =NULL ;UINT32 Type;ACPI_STATUS Status;
@@ -604,9 +603,8 @@ AcpiExPrepFieldValue (* opcode and operands -- since the BankValue * operands must be evaluated. */ - SecondDesc = ObjDesc->Common.NextObject; - SecondDesc->Extra.AmlStart =ACPI_CAST_PTR (ACPI_PARSE_OBJECT , Info->DataRegisterNode)->Named.Data; - SecondDesc->Extra.AmlLength =ACPI_CAST_PTR (ACPI_PARSE_OBJECT , Info->DataRegisterNode)->Named.Length; + ObjDesc->BankField.AmlStart =ACPI_CAST_PTR (ACPI_PARSE_OBJECT , Info->DataRegisterNode)->Named.Data; + ObjDesc->BankField.AmlLength =ACPI_CAST_PTR (ACPI_PARSE_OBJECT , Info->DataRegisterNode)->Named.Length;break ;
source/components/namespace/nsobject.c +0 -33
@@ -373,39 +373,6 @@ AcpiNsGetAttachedObject (return_PTR (Node->Object); } - -/******************************************************************************* -* -* FUNCTION: AcpiNsGetSecondaryObject -* -* PARAMETERS: Node - Namespace node -* -* RETURN: Current value of the object field from the Node whose -* handle is passed. -* -* DESCRIPTION: Obtain a secondary object associated with a namespace node. -* -******************************************************************************/ - -ACPI_OPERAND_OBJECT * -AcpiNsGetSecondaryObject ( -ACPI_OPERAND_OBJECT *ObjDesc) -{ -ACPI_FUNCTION_TRACE_PTR (NsGetSecondaryObject, ObjDesc); - - -if ((!ObjDesc) || - (ObjDesc->Common.Type==ACPI_TYPE_LOCAL_DATA ) || - (!ObjDesc->Common.NextObject) || - ((ObjDesc->Common.NextObject)->Common.Type ==ACPI_TYPE_LOCAL_DATA )) - { -return_PTR (NULL ); - } - -return_PTR (ObjDesc->Common.NextObject); -} - -/******************************************************************************* * * FUNCTION: AcpiNsAttachData
source/components/utilities/utalloc.c +0 -15
@@ -172,14 +172,6 @@ AcpiUtCreateCaches (return (Status); } - Status =AcpiOsCreateCache ("Acpi-Operand" ,sizeof (ACPI_OPERAND_OBJECT ), -ACPI_MAX_OBJECT_CACHE_DEPTH , &AcpiGbl_OperandCache); -if (ACPI_FAILURE (Status)) - { -return (Status); - } - -#ifdef ACPI_DBG_TRACK_ALLOCATIONS /* Memory allocation lists */
@@ -235,16 +227,9 @@ AcpiUtDeleteCaches ( (void )AcpiOsDeleteCache (AcpiGbl_StateCache); AcpiGbl_StateCache =NULL ; - (void )AcpiOsDeleteCache (AcpiGbl_OperandCache); - AcpiGbl_OperandCache =NULL ; - (void )AcpiOsDeleteCache (AcpiGbl_PsNodeCache); AcpiGbl_PsNodeCache =NULL ; - (void )AcpiOsDeleteCache (AcpiGbl_PsNodeExtCache); - AcpiGbl_PsNodeExtCache =NULL ; - -#ifdef ACPI_DBG_TRACK_ALLOCATIONS /* Debug only - display leftover memory allocation, if any */
source/components/utilities/utcopy.c +1 -1
@@ -807,7 +807,7 @@ AcpiUtCopySimpleObject (/* Copy the entire source object over the destination object*/ ACPI_MEMCPY ((char *) DestDesc, (char *) SourceDesc, -sizeof (ACPI_OPERAND_OBJECT )); +AcpiUtOperandSize (DestDesc->Common.Type));/* Restore the saved fields */
source/components/utilities/utdelete.c +1 -37
@@ -156,7 +156,6 @@ AcpiUtDeleteInternalObj ( {void *ObjPointer =NULL ;ACPI_OPERAND_OBJECT *HandlerDesc; -ACPI_OPERAND_OBJECT *SecondDesc;ACPI_OPERAND_OBJECT *NextDesc;
@@ -306,9 +305,6 @@ AcpiUtDeleteInternalObj (ACPI_DEBUG_PRINT ((ACPI_DB_ALLOCATIONS ,"***** Region %p\n" , Object)); - SecondDesc =AcpiNsGetSecondaryObject (Object); -if (SecondDesc) - {/* * Free the RegionContext if and only if the handler is one of the * default handlers -- and therefore, we created the context object
@@ -327,46 +323,14 @@ AcpiUtDeleteInternalObj ( (void ) HandlerDesc->AddressSpace.Setup (Object,ACPI_REGION_DEACTIVATE , HandlerDesc->AddressSpace.Context, - &SecondDesc->Extra.RegionContext); + &Object->Region.RegionContext); } }AcpiUtRemoveReference (HandlerDesc); } - -/* Now we can free the Extra object */ - -AcpiUtDeleteObjectDesc (SecondDesc); - }break ; - -case ACPI_TYPE_BUFFER_FIELD : - -ACPI_DEBUG_PRINT ((ACPI_DB_ALLOCATIONS , -"***** Buffer Field %p\n" , Object)); - - SecondDesc =AcpiNsGetSecondaryObject (Object); -if (SecondDesc) - { -AcpiUtDeleteObjectDesc (SecondDesc); - } -break ; - - -case ACPI_TYPE_LOCAL_BANK_FIELD : - -ACPI_DEBUG_PRINT ((ACPI_DB_ALLOCATIONS , -"***** Bank Field %p\n" , Object)); - - SecondDesc =AcpiNsGetSecondaryObject (Object); -if (SecondDesc) - { -AcpiUtDeleteObjectDesc (SecondDesc); - } -break ; - -default :break ; }
source/components/utilities/utobject.c +77 -90
213 lines not on this page · raw message
source/components/utilities/utxface.c +0 -1
@@ -699,7 +699,6 @@ AcpiPurgeCachedObjects (ACPI_FUNCTION_TRACE (AcpiPurgeCachedObjects); (void )AcpiOsPurgeCache (AcpiGbl_StateCache); - (void )AcpiOsPurgeCache (AcpiGbl_OperandCache); (void )AcpiOsPurgeCache (AcpiGbl_PsNodeCache); (void )AcpiOsPurgeCache (AcpiGbl_PsNodeExtCache);return_ACPI_STATUS (AE_OK );
source/include/acglobal.h +0 -1
@@ -264,7 +264,6 @@ ACPI_EXTERN ACPI_CACHE_T *AcpiGbl_NamespaceCache; ACPI_EXTERN ACPI_CACHE_T *AcpiGbl_StateCache; ACPI_EXTERN ACPI_CACHE_T *AcpiGbl_PsNodeCache; ACPI_EXTERN ACPI_CACHE_T *AcpiGbl_PsNodeExtCache; -ACPI_EXTERN ACPI_CACHE_T *AcpiGbl_OperandCache;/* Global handlers */
source/include/acnamesp.h +0 -4
@@ -385,10 +385,6 @@ ACPI_OPERAND_OBJECT *AcpiNsGetAttachedObject (ACPI_NAMESPACE_NODE *Node); -ACPI_OPERAND_OBJECT * -AcpiNsGetSecondaryObject ( -ACPI_OPERAND_OBJECT *ObjDesc); - ACPI_STATUS AcpiNsAttachData ( ACPI_NAMESPACE_NODE *Node,
source/include/acobject.h +8 -21
@@ -275,6 +275,10 @@ typedef struct acpi_object_regionunion acpi_operand_object *Next;ACPI_PHYSICAL_ADDRESS Address;UINT32 Length; +ACPI_NAMESPACE_NODE *Method_REG;/* _REG method for this region (if any) */ +void *RegionContext;/* Region-specific data */ +UINT8 *AmlStart; +UINT32 AmlLength; }ACPI_OBJECT_REGION ;
@@ -406,6 +410,8 @@ typedef struct acpi_object_bank_fieldACPI_COMMON_FIELD_INFO union acpi_operand_object *RegionObj; /* Containing OpRegion object */union acpi_operand_object *BankObj;/* BankSelect Register object */ +UINT8 *AmlStart; +UINT32 AmlLength; }ACPI_OBJECT_BANK_FIELD ;
@@ -432,6 +438,8 @@ typedef struct acpi_object_buffer_fieldACPI_OBJECT_COMMON_HEADER ACPI_COMMON_FIELD_INFOunion acpi_operand_object *BufferObj;/* Containing Buffer object */ +UINT8 *AmlStart; +UINT32 AmlLength; }ACPI_OBJECT_BUFFER_FIELD ;
@@ -511,25 +519,6 @@ typedef enum }ACPI_REFERENCE_CLASSES ; - -/* -* Extra object is used as additional storage for types that -* have AML code in their declarations (TermArgs) that must be -* evaluated at run time. -* -* Currently: Region and FieldUnit types -*/ -typedef struct acpi_object_extra -{ -ACPI_OBJECT_COMMON_HEADER - ACPI_NAMESPACE_NODE *Method_REG; /* _REG method for this region (if any) */ -void *RegionContext;/* Region-specific data */ -UINT8 *AmlStart; -UINT32 AmlLength; - -}ACPI_OBJECT_EXTRA ; - -/* Additional data that can be attached to namespace nodes */ typedef struct acpi_object_data
@@ -581,7 +570,6 @@ typedef union acpi_operand_objectACPI_OBJECT_NOTIFY_HANDLER Notify;ACPI_OBJECT_ADDR_HANDLER AddressSpace;ACPI_OBJECT_REFERENCE Reference; -ACPI_OBJECT_EXTRA Extra;ACPI_OBJECT_DATA Data;ACPI_OBJECT_CACHE_LIST Cache;
@@ -594,7 +582,6 @@ typedef union acpi_operand_object }ACPI_OPERAND_OBJECT ; -/****************************************************************************** * * ACPI_DESCRIPTOR - objects that share a common descriptor identifier
source/include/actypes.h +0 -1
@@ -679,7 +679,6 @@ typedef UINT32 ACPI_OBJECT_TYPE;* These are special object types that never appear in * a Namespace node, only in an ACPI_OPERAND_OBJECT */ -#define ACPI_TYPE_LOCAL_EXTRA 0x1C#define ACPI_TYPE_LOCAL_DATA 0x1D#define ACPI_TYPE_LOCAL_MAX 0x1D
source/include/acutils.h +1 -1
@@ -397,7 +397,7 @@ AcpiUtCopyIobjectToIobject (ACPI_OPERAND_OBJECT **DestDesc, ACPI_WALK_STATE *WalkState); - +ACPI_SIZE AcpiUtOperandSize (int Type);/* * utcreate - Object creation */
source/os_specific/service_layers/osunixxf.c +2 -0
@@ -575,6 +575,8 @@ AcpiOsDeleteSemaphore (return (AE_BAD_PARAMETER ); } +AcpiOsFree (Sem); +return (AE_OK ); }
Please explain further what this accomplishes. This removes the use of any cache for the acpi operand object? What about performance? That was the major reason the cache was added in the first place.
Quoted 17 lines
-----Original Message-----
From: Alexey Starikovskiy [mailto:[email protected]]
Sent: Friday, April 17, 2009 11:26 AM
To: Moore, Robert; Len Brown
Cc: ACPI Devel Maling List
Subject: [RFC][PATCH] ACPICA: Drop Operand cacheHi,
I've played with AcpiOperandObject union and corresponding cache. Removing the union does not seem to be viable -- patch easily overcomes .5 meg barrier, without any visible change. Dropping only the cache and making all individual objects allocated from heap requires smaller number of changes and chould make SLAB/SLUB developers happy.
Regards,
Alex.
Quoted 1 line · Robert
Please explain further what this accomplishes. This removes the use of any cache for the acpi operand object? What about performance? That was the major reason the cache was added in the first place.
Our cache implementation fights with memory debugger in Microsoft Visual C standard library. If you care about performance, the best way is to disable this memory debugger, as we don't use it anyway. You could accomplish it in two ways, one is to disable all DEBUG, the other is to only disable memory debugger.
With this patch, every object type is allowed to have it's own size, thus allowing separate optimization. For example, "extra" object, tied to region and field objects could be folded in to save both space and code, this optimization was implemented by Kuzmich some time ago, but was lost during layoffs.
Regards,
Alex.
Quoted 19 lines
Quoted 19 lines
-----Original Message-----
From: Alexey Starikovskiy [mailto:[email protected]]
Sent: Friday, April 17, 2009 11:26 AM
To: Moore, Robert; Len Brown
Cc: ACPI Devel Maling List
Subject: [RFC][PATCH] ACPICA: Drop Operand cacheHi,
I've played with AcpiOperandObject union and corresponding cache. Removing the union does not seem to be viable -- patch easily overcomes .5 meg barrier, without any visible change. Dropping only the cache and making all individual objects allocated from heap requires smaller number of changes and chould make SLAB/SLUB developers happy.
Regards,
Alex.
Quoted 4 lines · Alexey Starikovskiy
Quoted 1 line · Robert
Please explain further what this accomplishes. This removes the use of any cache for the acpi operand object? What about performance? That was the major reason the cache was added in the first place.
Our cache implementation fights with memory debugger in Microsoft Visual C standard library. If you care about performance, the best way is to disable this memory debugger, as we don't use it anyway. You could accomplish it in two ways, one is to disable all DEBUG, the other is to only disable memory debugger.
Here is the link to the offending MSVC flag description:
http://msdn.microsoft.com/en-us/library/10t349zs(VS.71).aspx
Regards,
Alex.
I'll take a look at this sometime next week.
Bob
Quoted 23 lines
-----Original Message-----
From: Alexey Starikovskiy [mailto:[email protected]]
Sent: Friday, April 17, 2009 1:07 PM
To: Moore, Robert
Cc: Len Brown; ACPI Devel Maling List
Subject: Re: [RFC][PATCH] ACPICA: Drop Operand cacheQuoted 10 lines · Alexey Starikovskiy
Quoted 3 lines · Robert
Please explain further what this accomplishes. This removes the use of any cache for the acpi operand object? What about performance? That was the major reason the cache was added in the first place.
Our cache implementation fights with memory debugger in Microsoft Visual C standard library. If you care about performance, the best way is to disable this memory debugger, as we don't use it anyway. You could accomplish it in two ways, one is to disable all DEBUG, the other is to only disable memory debugger.
Here is the link to the offending MSVC flag description:
http://msdn.microsoft.com/en-us/library/10t349zs(VS.71).aspxRegards,
Alex.
I've had a bit of time to start looking at this again.
I'm still a bit confused about what this is trying to accomplish. Is it a performance gain? Is it to reduce memory use or memory fragmentation? I know there has been discussion on and off concerning the use of caches, object sizes, the big union, etc., but please refresh me.
As far as the operand objects, once the tables are loaded and the namespace is initialized, these are all dynamic with a lifetime of at most the duration of an executing control method -- so I'm not clear as to what is to be gained by splitting a single-sized object into a bunch of differently-sized objects. One would *think* that it would be more efficient to just allocate the single-sized objects from a single fast cache.
Quoted 48 lines
-----Original Message-----
From: Alexey Starikovskiy [mailto:[email protected]]
Sent: Friday, April 17, 2009 12:56 PM
To: Moore, Robert
Cc: Len Brown; ACPI Devel Maling List
Subject: Re: [RFC][PATCH] ACPICA: Drop Operand cacheQuoted 1 line · Robert
Please explain further what this accomplishes. This removes the use of
any cache for the acpi operand object? What about performance? That was the major reason the cache was added in the first place.
Our cache implementation fights with memory debugger in Microsoft Visual C standard library. If you care about performance, the best way is to disable this memory debugger, as we don't use it anyway. You could accomplish it in two ways, one is to disable all DEBUG, the other is to only disable memory debugger.With this patch, every object type is allowed to have it's own size, thus allowing separate optimization. For example, "extra" object, tied to region and field objects could be folded in to save both space and code, this optimization was implemented by Kuzmich some time ago, but was lost during layoffs.
Regards,
Alex.Quoted 9 lines
Quoted 9 lines
-----Original Message-----
From: Alexey Starikovskiy [mailto:[email protected]]
Sent: Friday, April 17, 2009 11:26 AM
To: Moore, Robert; Len Brown
Cc: ACPI Devel Maling List
Subject: [RFC][PATCH] ACPICA: Drop Operand cacheQuoted 3 lines
Quoted 3 lines
Hi,
I've played with AcpiOperandObject union and corresponding cache.
Removing
Quoted 2 lines
Quoted 2 lines
the union does not seem to be viable -- patch easily overcomes .5 meg barrier, without any visible change. Dropping only the cache and making
all
Quoted 1 line
Quoted 1 line
individual objects allocated from heap requires smaller number of
changes
Quoted 4 lines
Quoted 4 lines
and chould make SLAB/SLUB developers happy.
Regards,
Alex.
Quoted 4 lines · Robert
I've had a bit of time to start looking at this again.
I'm still a bit confused about what this is trying to accomplish. Is it a performance gain?
Yes, for in-kernel use. It has no performance difference with userland tools compiled without memory debug. It has negative performance gain on tools compiled with memory debug.
Quoted 1 line
Is it to reduce memory use or memory fragmentation?
Yes, both. Kernel people don't like us to keep separate caches for hundred byte allocation every 5 seconds. it's a waist of kernel resources.
Quoted 1 line
I know there has been discussion on and off concerning the use of caches, object sizes, the big union, etc., but please refresh me.
Yes, there was a outside patch to replace kernel caching with ACPICA caching. Then I explained implementation of ACPICA caching, patch was dropped (good thing), but people suggested that we simplify ACPICA memory usage to just malloc and don't use fits-all scheme for objects. This is what my patch does -- it makes every object to only allocate it own size of memory.
They also suggested dropping the object union, but this seems not practical as it is, because of huge number of casts between objects and common part (I've tried to do this first, but the patch became about 600k in size, containing mostly casts). It is still possible to remove _use_ of object union there it is has benefits, for example, if function is supposed to only receive mutex object, there is a little reason to feed it with union.
Quoted 2 lines
As far as the operand objects, once the tables are loaded and the namespace is initialized, these are all dynamic with a lifetime of at most the duration of an executing control method -- so I'm not clear as to what is to be gained by splitting a single-sized object into a bunch of differently-sized objects. One would *think* that it would be more efficient to just allocate the single-sized objects from a single fast cache.
Malloc in all Unix/Linux implementations use the same-size object caches (slabs) for kernel allocation for two decades now. So, inside kernel we don't gain anything by re-implementing this, mostly because we don't care about CPU caches, NUMA memory locality, etc. There are several attempts to use slabs in malloc implementations for userspace libraries, but ACPICA is not that memory bound to require this.
Regards,
Alex.
Yes, I think maybe the cache stuff can go away. I see no performance improvement with the (local) cache at the application level -- in fact, it is actually slower.
I think the cache code was most useful during the early stages when we were debugging the dynamic object deletion and other object handling code, and for gathering our own memory use statistics.
With that being said, I don't want to do this all in one big step. I have noticed some instability if the local cache code is disturbed or if the cache acquire/release object interfaces are implemented with simple calls to malloc/free. The logical steps would seem to me to be:
1) Implement the AcpiOs* cache interfaces with simple malloc/free calls.
2) Replace all acquire/release calls with malloc/free calls, remove cache create/delete/purge calls, remove all cache statistical information and debugger cache support.
3) Allocate only the size needed for the desired objects, not the union size.
Each step has risk, so I would not want to do them all at once.
Also, I'd like to poll a few of our other major users to get their feedback and input.
Thanks,
Bob
Quoted 51 lines
-----Original Message-----
From: Alexey Starikovskiy [mailto:[email protected]]
Sent: Friday, April 24, 2009 7:22 AM
To: Moore, Robert
Cc: Len Brown; ACPI Devel Maling List
Subject: Re: [RFC][PATCH] ACPICA: Drop Operand cacheQuoted 4 lines · Robert
I've had a bit of time to start looking at this again.
I'm still a bit confused about what this is trying to accomplish. Is it a performance gain?
Yes, for in-kernel use. It has no performance difference with userland tools compiled without memory debug. It has negative performance gain on tools compiled with memory debug.
Quoted 1 line
Is it to reduce memory use or memory fragmentation?
Yes, both. Kernel people don't like us to keep separate caches for hundred byte allocation every 5 seconds. it's a waist of kernel resources.
Quoted 1 line
I know there has been discussion on and off concerning the use of caches,
object sizes, the big union, etc., but please refresh me.
Yes, there was a outside patch to replace kernel caching with ACPICA caching. Then I explained implementation of ACPICA caching, patch was dropped (good thing), but people suggested that we simplify ACPICA memory usage to just malloc and don't use fits-all scheme for objects. This is what my patch does -- it makes every object to only allocate it own size of memory.They also suggested dropping the object union, but this seems not practical as it is, because of huge number of casts between objects and common part (I've tried to do this first, but the patch became about 600k in size, containing mostly casts).
It is still possible to remove _use_ of object union there it is has benefits, for example, if function is supposed to only receive mutex object, there is a little reason to feed it with union.Quoted 2 lines
As far as the operand objects, once the tables are loaded and the
namespace is initialized, these are all dynamic with a lifetime of at
Quoted 1 line
most the duration of an executing control method -- so I'm not clear as
to what is to be gained by splitting a single-sized object into
Quoted 1 line
a bunch of differently-sized objects. One would *think* that it would be
more efficient to just allocate the single-sized objects
Quoted 1 line
from a single fast cache.
Malloc in all Unix/Linux implementations use the same-size object caches (slabs) for kernel allocation for two decades now. So, inside kernel we don't gain anything by re-implementing this, mostly because we don't care about CPU caches, NUMA memory locality, etc.
There are several attempts to use slabs in malloc implementations for userspace libraries, but ACPICA is not that memory bound to require this.Regards,
Alex.