Method and device for optimizing inter-process communication related resources

Abstract

The invention relates to an inter-process communication related resource optimization method and device, computer equipment, a storage medium and a computer program product. According to the method, the binder communication related process is processed by adopting the secondary linked list, so that quick searching and synchronous grouping in the cgroup are facilitated, and the management efficiency is high; a cross-module calling mode is adopted, a binder drive processing flow is combined with a cgroup module processing flow, and resource allocation is optimized in a finer-grained mode on the basis that real-time and synchronous communication is not affected; besides, resource synchronous grouping and allocation are carried out among the processes for establishing binder communication connection, so that resources in foreground and background processes compete for resources at the same high level under the scenes of media playing and the like, and the situation that partial processes are changed to be grouped for multiple times and groups are not matched when synchronous communication is carried out again after the method is adopted is processed. Reasonable allocation and efficient operation of binder communication related process resources are comprehensively realized, and then the power consumption loss is reduced.

Description

Technical Field

[0001] The present application relates to the technical field of resource allocation, and in particular to a method and device for optimizing resources related to inter-process communication. Background Art

[0002] With the development of operating system technology, resource allocation technology has emerged, especially resource management in the process of using Binder communication in Android system. This technology mainly deals with resource coordination between applications and background services to support efficient operation of the system. In traditional technology, the operating system dynamically adjusts the allocation of resources such as CPU and memory according to the foreground or background status of the application. Foreground applications usually get higher resource allocation to ensure user experience, while background applications are allocated fewer resources.

[0003] However, there are some problems with the current resource allocation method. When high-performance foreground applications frequently communicate with background services through Binder, if the background services fail to obtain sufficient resource support, it will lead to resource contention processing deviations, such as slower processing speed and lower frame rate. In addition, when the foreground application retreats to the background or is closed, if the background service continues to maintain a high resource allocation share, it will also cause power consumption waste. This resource allocation strategy not only leads to unnecessary long-term power consumption in high-performance states, but also impairs the user experience in low-performance states, which violates the overall goal of the operating system to pursue high performance and low power consumption.

[0004] Therefore, it is necessary to design an optimization method for inter-process communication related resources, which should be able to ensure the consistency of resource allocation and avoid power consumption loss caused by mismatch of communication related process resources. This will help improve the overall performance and efficiency of the operating system while reducing unnecessary energy consumption. Summary of the invention

[0005] Based on this, it is necessary to provide a method, device, computer equipment, computer-readable storage medium and computer program product for optimizing inter-process communication-related resources, which can avoid power consumption loss caused by mismatch of communication-related process resources, and can effectively optimize the resource allocation of binder communication-related processes, and reduce the problems of poor system performance and power consumption coordination caused by unbalanced resource allocation between the communicating parties.

[0006] In a first aspect, the present application provides a method for optimizing resources related to inter-process communication, the method comprising:

[0007] The reference relationship between the processes at both ends of the Binder communication is synchronized to the cgroup module through a cross-module call interface, wherein the two ends of the Binder communication include the client and the server;

[0008] According to the reference relationship, a related server is synchronously adjusted when a client resource group of Binder communication changes, wherein the client resource group refers to a resource management unit to which the client application belongs;

[0009] For the Binder communication process of the client resource group that is not synchronized, synchronize the changes of the client resource group to the server when synchronous communication occurs;

[0010] After the Binder communication process is completed, the server is restored.

[0011] Resource group, all the Binder communication related processes are included in the management to achieve optimal allocation of related resources.

[0012] Optionally, a Binder relationship structure is added when the cgroup module is started in the early stage, and the Binder relationship structure adopts a two-level linked list structure, the first level is a client proxy linked list, and the second level is a server proxy linked list;

[0013] Among them, the client proxy linked list is used to store the proxy information of all client processes, the server proxy linked list is used to store the proxy information of all server processes, and the Binder relationship structure is used to manage the reference relationship of the Binder communication through the secondary linked list structure.

[0014] Optionally, synchronizing the reference relationship between processes at both ends of Binder communication to the cgroup module through a cross-module calling interface includes:

[0015] The reference relationship when the processes at both ends of the communication in the Binder driver add or remove references to each other is synchronized to the Binder relationship structure of the cgroup module through the cross-module calling interface, and the secondary linked list structure is updated in real time.

[0016] Optionally, synchronizing the reference relationship between processes at both ends of Binder communication to the cgroup module through a cross-module calling interface also includes:

[0017] When the processes at both ends of the communication are disconnected and the reference is removed in the Binder driver, the reference relationship is synchronized to the Binder relationship structure of the cgroup module through the cross-module call interface, and the secondary linked list structure is updated in real time.

[0018] Optionally, the method further includes:

[0019] In response to the client proxy linked list in the Binder relationship structure not existing, creating a client proxy and adding it to the Binder relationship structure, and creating a server proxy and adding it to the client proxy;

[0020] In response to the existence of the client proxy linked list in the Binder relationship structure, traverse the client proxy linked list and find whether there is a corresponding client proxy. If the client proxy does not exist, create a client proxy and add it to the Binder relationship structure, and create a server proxy and add it to the client proxy.

[0021] In response to the existence of both the client proxy linked list and the client proxy, a search is performed to determine whether a corresponding server proxy exists in the server proxy linked list. If the server proxy does not exist, a server proxy is created and added to the client proxy in the server proxy linked list. If the server proxy exists, a reference count of the server proxy is increased.

[0022] Optionally, when at least two binder communication relationships exist simultaneously between the client and the server process, the method further includes:

[0023] Remove redundant connections and reference relationships between the two ends of the binder communication through the cross-module calling interface, and synchronize the reference relationship between the two ends of the binder communication to the cgroup module;

[0024] Extracting messages from the client and the server through the cgroup module;

[0025] Determine whether the client proxy linked list of the Binder relationship structure exists. If not, end the process; if the client proxy linked list of the Binder relationship structure exists, traverse the client proxy linked list to determine whether there is a corresponding client proxy;

[0026] If the corresponding client agent does not exist, the process ends; if the corresponding client agent exists, it is determined whether there is a corresponding server agent in the client agent linked list where the client agent is located;

[0027] If the corresponding server agent does not exist, the process ends; if the corresponding server agent exists, the reference count of the corresponding server agent is reduced until it is reduced to 1, and then the server agent linked list corresponding to the client agent is removed.

[0028] Optionally, the step of synchronously adjusting the relevant server when the client resource group of Binder communication changes according to the reference relationship includes:

[0029] When the client resource group of the Binder communication changes, the client sends a synchronization message to the server, and the client process runs and starts to execute binder_transaction;

[0030] The thread of the server starts to read the synchronization message to execute binder_thread_read, and synchronizes the reference relationship to the cgroup module through the cross-module call interface;

[0031] In the cgroup module, according to the reference relationship between the client and the server, the cgroup group migration method is adopted to migrate the server process to the resource group to which the client belongs, and the resource group to which the server previously belonged is saved;

[0032] The server provides feedback for the synchronization message by executing binder_transaction;

[0033] In the binder_transaction feedback process, the interface is called across modules and runs to the cgroup module.

[0034] In the cgroup module, the cgroup group migration method is adopted to perform migration, and the server process is moved from the resource group to which the current client belongs to the resource group to which the server previously belonged.

[0035] Optionally, in the cgroup module, migration is performed using a cgroup group migration method, including:

[0036] Add the pointer *restoreCgroups of the css_set structure to the server thread structure;

[0037] Save the css_set structure corresponding to the server thread structure to *restoreCgroups, and traverse the client cgrp_links list to obtain each cgroup group to which it belongs;

[0038] Use cgroup_attach_task to migrate the server thread structure to each cgroup group to which each client thread belongs.

[0039] Optionally, in the cgroup module, the migration is performed by using a cgroup group migration method, including:

[0040] Get the pointer *restoreCgroups of the css_set structure saved by the server thread structure, traverse the server cgrp_links list to get each cgroup group to which it belongs, and use cgroup_attach_task to migrate the server thread structure to each cgroup group to which each server thread previously belonged.

[0041] In a second aspect, the present application provides a device for optimizing resources related to inter-process communication, the device comprising:

[0042] A relationship synchronization module is used to synchronize the reference relationship of processes at both ends of Binder communication to the cgroup module through a cross-module call interface, wherein the two ends of the Binder communication include the client and the server;

[0043] A synchronization adjustment module, used for synchronously adjusting the relevant server when the client resource group of Binder communication changes according to the reference relationship, wherein the client resource group refers to the resource management unit to which the client application belongs;

[0044] A change synchronization module, for synchronizing the changes of the client resource group to the server when synchronous communication occurs for the Binder communication process of the client resource group that is not synchronized;

[0045] The optimization allocation module is used to restore the server resource group after the Binder communication process is completed. All the Binder communication related processes are included in the management to achieve the optimization allocation of related resources.

[0046] In a third aspect, the present application further provides a computer device. The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the following steps when executing the computer program:

[0047] The reference relationship between the processes at both ends of the Binder communication is synchronized to the cgroup module through a cross-module call interface, wherein the two ends of the Binder communication include the client and the server;

[0048] According to the reference relationship, a related server is synchronously adjusted when a client resource group of Binder communication changes, wherein the client resource group refers to a resource management unit to which the client application belongs;

[0049] For the Binder communication process of the client resource group that is not synchronized, synchronize the changes of the client resource group to the server when synchronous communication occurs;

[0050] After the Binder communication process is completed, the server is restored.

[0051] In a fourth aspect, the present application further provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the following steps are implemented:

[0052] The reference relationship between the processes at both ends of the Binder communication is synchronized to the cgroup module through a cross-module call interface, wherein the two ends of the Binder communication include the client and the server;

[0053] According to the reference relationship, a related server is synchronously adjusted when a client resource group of Binder communication changes, wherein the client resource group refers to a resource management unit to which the client application belongs;

[0054] For the Binder communication process of the client resource group that is not synchronized, synchronize the changes of the client resource group to the server when synchronous communication occurs;

[0055] After the Binder communication process is completed, the server is restored.

[0056] In a fifth aspect, the present application further provides a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, the following steps are implemented:

[0057] The reference relationship between the processes at both ends of the Binder communication is synchronized to the cgroup module through a cross-module call interface, wherein the two ends of the Binder communication include the client and the server;

[0058] According to the reference relationship, a related server is synchronously adjusted when a client resource group of Binder communication changes, wherein the client resource group refers to a resource management unit to which the client application belongs;

[0059] For the Binder communication process of the client resource group that is not synchronized, synchronize the changes of the client resource group to the server when synchronous communication occurs;

[0060] After the Binder communication process is completed, the server is restored.

[0061] The above-mentioned inter-process communication related resource optimization method, device, computer equipment, storage medium and computer program product.

[0062] The invention has the following advantages:

[0063] A two-level linked list is used to process binder communication-related processes, which is convenient for fast search and synchronization of groups in cgroup and has high management efficiency. A cross-module calling method is adopted to combine the processing flow in the binder driver with the processing flow of the cgroup module, and optimize resource allocation in a finer granularity without affecting real-time and synchronous communication. In addition, not only are resources synchronously grouped and allocated between processes that establish binder communication connections, so that resources in the foreground and background processes in scenarios such as media playback compete for resources at the same high level, but also some processes that have changed after the above method are grouped multiple times, and the situation where the groups do not match when synchronous communication is performed again is handled, so as to fully realize the reasonable allocation and efficient operation of binder communication-related process resources, thereby reducing power consumption losses. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] Figure 1 A schematic diagram of a flow chart of a method for optimizing resources related to inter-process communication in one embodiment;

[0065] Figure 2 A schematic flow chart of a method for optimizing inter-process communication related resources in another embodiment;

[0066] Figure 3 A schematic diagram of the data structure relationship of the resource allocation optimization method for binder-related processes;

[0067] Figure 4 A schematic flow chart of a method for optimizing inter-process communication related resources in another embodiment;

[0068] Figure 5 A schematic diagram of a resource allocation optimization process for a binder synchronous communication process of a resource allocation optimization method for binder-related processes. DETAILED DESCRIPTION

[0069] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0070] Example 1

[0071] In one embodiment, Figure 1 As shown, a method for optimizing resources related to inter-process communication is provided, comprising the following steps:

[0072] Step 101, synchronizing the reference relationship between processes at both ends of Binder communication to the cgroup module through a cross-module call interface, wherein the two ends of Binder communication include a client and a server.

[0073] Among them, when the processes at both ends of the communication in the binder driver add or remove references to each other, the reference relationship between the processes at both ends of the Binder communication is synchronized to the cgroup module through the cross-module call interface.

[0074] Step 102 , synchronously adjusting the relevant server when the client resource group of Binder communication changes according to the reference relationship, wherein the client resource group refers to the resource management unit to which the client application belongs.

[0075] In a possible implementation, the cgroup module uses a secondary linked list to manage the processes at both ends of the communication, and adjusts all related servers synchronously when the client resource group of the communication changes, to ensure the consistency of resource allocation of communication-related processes, improve communication efficiency and reduce power consumption loss. Among them, the client resource group refers to the resource group that needs to be restored after the Binder communication is completed.

[0076] Step 103: For the Binder communication process whose client resource group is not synchronized, the changes of the client resource group are synchronized to the server when synchronous communication occurs.

[0077] In case some processes are grouped multiple times and the groups do not match when synchronous communication occurs again, the client resource group changes are synchronized to the server when synchronous communication occurs.

[0078] Step 104: After the Binder communication process is completed, the server resource group is restored, and all Binder communication-related processes are brought under management to achieve optimal allocation of related resources.

[0079] When the communication is completed, the server resource group is restored, so that all processes related to binder communication are managed and related resources can be optimally allocated.

[0080] Example 2

[0081] In one embodiment, Figure 2 As shown, another method for optimizing inter-process communication related resources is provided, including the following steps:

[0082] Step 201, through the cross-module call interface, the reference relationship when the processes at both ends of the communication in the Binder driver add or remove references to each other is synchronized to the Binder relationship structure of the cgroup module, and the secondary linked list structure is updated in real time.

[0083] In a possible implementation, a binder relationship structure is added during the early startup of the cgroup, which is used to synchronize the corresponding relationship to the binder relationship structure when the binder adds a reference. The binder relationship structure adopts a two-level linked list structure, the first level is the client proxy linked list, and the second level is the server proxy linked list. Since the client may establish connections with multiple server processes at the same time, there may be multiple binder communication relationships between the same two processes. Therefore, the two-level linked list structure can efficiently handle complex and repeated communication relationships and meet the uniqueness requirements of corresponding process processing.

[0084] See Figure 3 The data structure relationship diagram of the resource allocation optimization method for binder-related processes shown in the figure, this embodiment provides a client_link type structure, and an instance of this type init_client_link is established and initialized during the cgroup module initialization process, which is used to include a binder relationship structure. The structure members include but are not limited to the following: Its members include but are not limited to a linked list for storing clients and a variable for recording the number of existing clients:

[0085] struct client_link{

[0086] struct list_head binder_clients;

[0087] unsigned int client_nr;

[0088] };

[0089] Among them, binder_clients is a linked list that stores clients, that is, a first-level client proxy linked list, and client_nr is a variable that records the number of existing clients.

[0090] In the binder driver, a binder_node is allocated to the service object of each server process, which belongs to the binder_proc of the server process, and a reference object binder_ref is allocated to each reference of each client process. Therefore, when the binder driver adds binder_ref, the binder process entity binder_proc is found by the binder_ref layer by layer, and then the server process structure is found by the process entity, and is passed to the cgroup module through the cross-module call interface together with the client process. The reason why the present invention does not use binder_proc as a parameter to pass to the cgroup module for processing is that binder_proc cannot uniquely represent a binder communication process, because a process may be the server or client of multiple processes, and the same two processes may also communicate through multiple binder communication processes, and each time a communication connection is established, a reference to a server by a client must be created, so binder_ref can be passed to the cgroup module as a representative of a communication establishment. In order to facilitate the rapid finding of the server of a client process in the removal reference process, the server can be recorded in the reference object before being passed to the cgroup module above to speed up the processing speed during removal.

[0091] See Figure 2 This embodiment provides a client proxy structure to manage client information in the cgroup module. The structure members include but are not limited to the following:

[0092] struct client_proxy{

[0093] pid_t pid;

[0094] struct task_struct *client;

[0095] struct list_head binder_servers;

[0096] struct list_head client_list;

[0097] unsigned int server_nr;

[0098] };

[0099] Among them, pid is the client process number, client is the client process, binder_servers is the server_list linked list storing server_proxy, that is, the secondary server proxy linked list, client_list is the binder_clients linked list stored in client_link, and server_nr is the number of servers bound to this client.

[0100] In addition, considering the above content that "the Binder relationship structure adopts a two-level linked list structure, the first level is the client proxy linked list, and the second level is the server proxy linked list", if you encounter a situation where the linked list does not exist, you will need an additional supplementary solution, as follows.

[0101] First, if the client proxy linked list in the Binder relationship structure does not exist, a client proxy is created and added to the Binder relationship structure, and a server proxy is created and added to the client proxy.

[0102] The second method is to traverse the client proxy list in the Binder relationship structure to find out whether there is a corresponding client proxy. If the client proxy does not exist, create a client proxy and add it to the Binder relationship structure, and create a server proxy and add it to the client proxy.

[0103] The third type is that in response to the existence of both the client proxy list and the client proxy, a search is performed in the server proxy list to determine whether a corresponding server proxy exists. If the server proxy does not exist, a server proxy is created and added to the client proxy in the server proxy list. If the server proxy exists, a reference count of the server proxy is increased.

[0104] In a possible implementation, the above three situations are illustrated as examples. The cgroup module extracts the client and server messages, determines whether the first-level linked list (i.e., the client proxy linked list of the client_proxy type) in the init_client_link type of client_link exists, and if not, creates a client proxy using the client process information and adds it to the init_client_link as a linked list. At the same time, since the newly created client proxy must not have a corresponding server proxy, a server-side proxy of the server_proxy type is created using the server-side process information and added to the client proxy as a linked list; if the client proxy linked list of init_client_link exists, the client proxy linked list is traversed to find out whether there is a proxy corresponding to this client. If not, the client proxy is created using the client process information and added to init_client_link as a linked list. At the same time, since the newly created client proxy must not have a corresponding server proxy, a server-side proxy of the server_proxy type is created using the server process information and added to the client proxy as a linked list; if the client proxy linked list of init_client_link exists, and the client proxy linked list has a proxy for this client, then find out whether there is a proxy corresponding to this server in the server proxy linked list of this client's proxy. If not, the server proxy is created using the server process information and added to the client proxy as a linked list; if it exists, the reference count of the server proxy is increased by 1.

[0105] In addition, threads can be migrated or processes can be migrated in cgroup, and the migrated process is all threads in the thread group of the migrated process. After managing the addition or removal of binder reference relationships, when the client causes the process group to migrate due to multiple entrances, in this embodiment, when the client process migration is completed, the server processes managed in all secondary linked lists are triggered to migrate synchronously, specifically including the following steps: determine whether the client proxy linked list of init_client_link exists, if not, it means that the communication relationship is not recorded and managed, then the process is terminated, which is fault-tolerant processing; if the client proxy linked list of init_client_link exists, then traverse the client proxy linked list to determine whether there is a proxy for this client, if not, then the process is terminated; if there is a proxy for this client, then determine whether there is a proxy for this server in the client proxy linked list, if not, then the process is terminated; if there is a proxy for this server, then recursively call the migration action to migrate the server to the client group. When the server or client exchanges roles with other processes, the associated processes can be coordinated and scheduled, so as to adjust the process group in a more fine-grained manner, thereby avoiding waste of resources and power consumption. In asynchronous communication scenarios, when the communication process feedback message time is uncontrollable, the present invention can be used to avoid the phenomenon of priority inversion caused by inconsistent resource proportions at both ends of the communication when the asynchronous message returns, and the urgently needed resources cannot be correctly scheduled. In some server scenarios connected to multiple clients, the change in the proportion of client process resources reflects the user's current needs to a certain extent. When the proportion of client process resources close to the user becomes larger, the method of the present invention is used to synchronize the proportion of server resources, so that the system as a whole can be adjusted according to the user's intention. For the server connected to multiple clients, the server adjusts according to the last adjusted client, which is more in line with the user's business purpose.

[0106] This embodiment provides a server proxy structure to manage server information in the cgroup module. The structure members include but are not limited to the following:

[0107] struct server_proxy{

[0108] pid_t pid;

[0109] struct task_struct *server;

[0110] struct list_head server_list;

[0111] unsigned int ref_count;

[0112] };

[0113] Among them, pid is the server process number, server is the server process, server_list is the binder_servers linked list stored in client_proxy, ref_count is the reference count. When the same two processes repeatedly call the interface due to different binder services, the reference is increased, so that the same server is no longer stored repeatedly; when removing the reference, the last binder service reference is removed, and the server will be removed from the linked list.

[0114] Step 202, when the processes at both ends of the communication are disconnected and the reference is removed in the Binder driver, the reference relationship is synchronized to the Binder relationship structure of the cgroup module through the cross-module call interface, and the secondary linked list structure is updated in real time.

[0115] Step 202 and step 201 may be in a parallel processing relationship, that is, when the processes at both ends of the communication are disconnected and the reference is removed in the Binder driver, the reference relationship is synchronized to the Binder relationship structure of the cgroup module through the cross-module call interface, and the secondary linked list structure is updated in real time.

[0116] Specifically, in the synchronous communication process of step 203, when the client initiates communication to the server, the client's specific communication thread resource group is recorded. After waking up the server thread, the client resource group is synchronized, and the task is processed as quickly as possible with the resource allocation of the same resource group. The previous resource group itself is restored during the server message feedback process.

[0117] Step 203: Synchronize and adjust the relevant server when the client resource group of Binder communication changes according to the reference relationship.

[0118] The client resource group refers to the resource management unit to which the client application belongs. In a possible implementation, step 203 (ie, step 102 in the embodiment) includes the following sub-steps.

[0119] Step 2031, when the client resource group of Binder communication changes, the client sends a synchronization message to the server, and the client process runs and starts to execute binder_transaction.

[0120] Among them, reference Figure 5 , Figure 5Schematic diagram of resource allocation optimization process of binder synchronous communication process for resource allocation optimization method of binder related processes. During the inter-process communication initialization process, the client Looper thread first calls the kernel binder driver to register itself at the bottom layer to execute the incoming method call. If there are no other transactions to be processed, it goes into sleep and waits for the waiting queue of a specific node. The thread will not be scheduled until the client thread performs a wake-up operation on the waiting queue. When the client needs to invoke the remote communication process due to business and behavioral input and sends a synchronous message to the server, the client process runs at this time and starts to execute binder_transaction. The function is serialized with the corresponding parameters from the client and forwarded to the kernel driver through ioctl() call. After determining the required target node, the serialized information is copied to the FIFO queue, which contains all transactions to be executed by the node. Then the wake-up operation is performed in the waiting queue of the target node to wake up all waiting threads on the server. While waiting for the response from the server, the client thread puts itself into a sleep state.

[0121] Step 2032, the server thread starts to read the synchronization message to execute binder_thread_read, and synchronizes the reference relationship to the cgroup module through the cross-module call interface.

[0122] In a possible implementation, when communication is required during the operation of the Binder module, the client and server structures are interacted with the cgroup module, and the server is moved to the resource group to which the client belongs in the linked list saved by the cgroup module itself. After the communication is completed, the Binder module tells the cgroup module and then moves the server back to the original resource group.

[0123] Among them, one of the server threads serving this client thread will start reading the client message, execute binder_thread_read, and call the cgroup module across modules.

[0124] Step 2033, in the cgroup module, according to the reference relationship between the client and the server, the cgroup group migration method is used to migrate the server process to the resource group to which the client belongs, and the resource group to which the server previously belonged is saved.

[0125] The reference relationship is the server corresponding to the client, which is the reference relationship between the two. In Binder, they are such a reference relationship. When the client sends a message, it interactively informs the cgroup module that there is communication between the client and the server. The simplified reference relationship saved in the cgroup module allows the server to move to the resource group where the client is located. After the communication is completed, the server returns to the original resource group.

[0126] In a possible implementation, step 2033 includes the following contents 1 to 2.

[0127] Content 1: Add the pointer *restoreCgroups of the css_set structure to the server thread structure;

[0128] Content 2: Save the css_set structure corresponding to the server thread structure to *restoreCgroups, and traverse the client cgrp_links list to obtain each cgroup group to which it belongs;

[0129] Content 3: Use cgroup_attach_task to migrate the server thread structure to each cgroup group to which each client thread belongs.

[0130] In another possible implementation, step 1023 includes the following contents. First, a pointer *restoreCgroups of a css_set structure is added to the server thread structure, and then the corresponding css_set structures are found according to the client and server thread structures, and the css_set structure corresponding to the server thread is saved to *restoreCgroups. If it is determined that the two are not in the same css_set, the cg_list of the server thread is cleared, and it is reinitialized and added to the end of the client thread cg_list linked list.

[0131] Cgroup group migration can synchronize the cpuctl, schedtune, cpuset, and memory groups where the client thread is located to the server thread. Since the client thread is closer to the user, its priority allocation and resource allocation are more in line with the user's intention, so that the server thread and the client thread run under the resource quota controlled by the same group, such as the same CPU resources, memory resources, and boost speed-up performance, which can ensure the consistency of performance and power consumption adjustment at both ends of the communication, consistency with user intentions, and improve the overall performance-power ratio of the system. For example, some games with large computing volume and multimedia playback require a large proportion of system resources. When the user's performance requirements exceed the power consumption requirements, the client thread meets the user's requirements and makes the background dependent threads meet the same requirements at the same time, which can meet the user's smooth experience. In some daily office software and other scenarios, the proportion of system resources required to be occupied is small. When the user's performance requirements are not high, the resource proportion can be reduced accordingly to save power consumption. At this time, the client thread meets the user's requirements and makes the background dependent threads meet the same requirements at the same time, which can meet the user experience and reduce power consumption.

[0132] Step 2034: The server side feeds back the synchronization message by executing binder_transaction.

[0133] See Figure 5 After the cgroup migration is completed, the server polls the transaction from the FIFO queue and returns the control flow to the server application level Looper thread. At this time, the original call function is deserialized, the specified method is called, and the operation is performed. After the operation is completed, the server starts to feedback the above message and executes binder_transaction. In the subsequent process of binder_transaction, it is determined whether it is a feedback process. If it is, it calls the cgroup module across modules. In the cgroup module, the cgroup group migration method is used for migration.

[0134] Step 2035, in the binder_transaction feedback process, the cross-module call interface is used to run to the cgroup module.

[0135] Step 2036, in the cgroup module, the cgroup group migration method is used to perform migration, and the server process is moved from the resource group to which the current client belongs to the resource group to which the server previously belonged.

[0136] In a possible implementation, step 2036 includes taking the pointer *restoreCgroups of the css_set structure saved by the server thread structure, traversing the server cgrp_links linked list to obtain each cgroup group to which it belongs, and using cgroup_attach_task to migrate the server thread structure to each cgroup group to which each server thread previously belonged.

[0137] In another possible implementation, step 1025 includes obtaining a pointer *restoreCgroups of a css_set structure saved in the server thread structure, and adding the thread structure of the server thread to a tasks linked list of restoreCgroups to implement migration of the minimum unit of cgroup.

[0138] Furthermore, after the cgroup group is migrated back, the specified method is called, the return value is serialized, and the result is copied to the client node. At the same time, the client thread immediately enters a dormant state until a new transaction arrives. After the client thread is awakened, the result is deserialized and processing continues.

[0139] Step 204: for the Binder communication process whose client resource group is not synchronized, synchronize the changes of the client resource group to the server when synchronous communication occurs.

[0140] Step 205: After the Binder communication process is completed, the server resource group is restored, and all Binder communication-related processes are brought under management to achieve optimal allocation of related resources.

[0141] Example 3

[0142] On the basis of the above embodiment, when at least two binder communication relationships exist between the processes of the client and the server at the same time, the method further includes the following steps: Figure 4 It is a flowchart of a method for optimizing resources related to inter-process communication in another embodiment.

[0143] Step 401, remove redundant connections and reference relationships between two ends of binder communication through a cross-module calling interface, and synchronize the reference relationship between two ends of binder communication to the cgroup module.

[0144] The reference relationship between the client and the server is synchronized to the cgroup module through the cross-module call interface. That is, the reference relationship in Binder is synchronized to the cgroup module, and the cgroup module analyzes whether there are repeated references between the two. If there are duplicates, they are deleted. Once the relationship between the client and the server is established, it can be saved and processed, and there is no duplicate relationship.

[0145] Step 402: extract the messages of the client and the server through the cgroup module.

[0146] Step 403, determine whether the client proxy linked list of the Binder relationship structure exists. If not, end the process; if the client proxy linked list of the Binder relationship structure exists, traverse the client proxy linked list to determine whether the corresponding client proxy exists.

[0147] Step 404: if there is no corresponding client proxy, the process ends; if there is a corresponding client proxy, it is determined whether there is a corresponding server proxy in the client proxy linked list where the client proxy is located.

[0148] Step 405: if there is no corresponding server proxy, the process ends; if there is a corresponding server proxy, the reference count of the corresponding server proxy is reduced until it is reduced to 1, and then the server proxy linked list corresponding to the client proxy is removed.

[0149] In a possible implementation, since the binder_proc on the communication server allocates a reference object binder_ref to each reference of each client process when adding references and establishing connections in the early stage, when the two parties in binder communication disconnect, the client process reference object binder_ref of the binder_proc on the communication server needs to be removed. The removal process is similar to the addition process, and binder_proc cannot be used as a parameter to pass to the cgroup module for processing. A binder_proc process may be the server or client of multiple processes, and the same two processes may also communicate through multiple Binder communication processes. Therefore, when the binder_ref reference that can truly represent a communication relationship is removed, the information of the two communicating parties should be synchronized to the cgroup module. In the early stage, the server corresponding to a reference has been recorded in the client's reference object. At this time, the server of a client process can be quickly found, which speeds up the processing speed when removing. The cgroup module extracts the client and server messages and determines whether the client proxy list of init_client_link exists. If not, it means that the communication relationship is not recorded and managed, and the process ends. This is fault-tolerant processing to avoid program vulnerabilities. If the client proxy list of init_client_link exists, the client proxy list is traversed to determine whether there is a proxy for this client. If there is no proxy for this client, the process ends. If there is a proxy for this client, it is determined whether there is a proxy for this server in the client proxy list. If there is no proxy for this server, the process ends. If there is a proxy for this server, the reference count of the server proxy is reduced. If it is reduced to 1, the server proxy list in this client proxy is removed.

[0150] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0151] Based on the same inventive concept, the embodiment of the present application also provides an inter-process communication related resource optimization device for implementing the inter-process communication related resource optimization method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in the one or more inter-process communication related resource optimization device embodiments provided below can refer to the limitations of the inter-process communication related resource optimization method above, and will not be repeated here.

[0152] In one embodiment, a device for optimizing resources related to inter-process communication is also provided, including:

[0153] A relationship synchronization module is used to synchronize the reference relationship of processes at both ends of Binder communication to the cgroup module through a cross-module call interface, wherein the two ends of the Binder communication include the client and the server;

[0154] A synchronization adjustment module, used for synchronously adjusting the relevant server when the client resource group of Binder communication changes according to the reference relationship, wherein the client resource group refers to the resource management unit to which the client application belongs;

[0155] A change synchronization module, for synchronizing the changes of the client resource group to the server when synchronous communication occurs for the Binder communication process of the client resource group that is not synchronized;

[0156] The optimization allocation module is used to restore the server resource group after the Binder communication process is completed. All the Binder communication related processes are included in the management to achieve the optimization allocation of related resources.

[0157] Optionally, a Binder relationship structure is added when the cgroup module is started in the early stage, and the Binder relationship structure adopts a two-level linked list structure, the first level is a client proxy linked list, and the second level is a server proxy linked list;

[0158] Among them, the client proxy linked list is used to store the proxy information of all client processes, the server proxy linked list is used to store the proxy information of all server processes, and the Binder relationship structure is used to manage the reference relationship of the Binder communication through the secondary linked list structure.

[0159] Optionally, the relationship synchronization module includes:

[0160] The first synchronization unit is used to synchronize the reference relationship when the two communication end processes in the Binder driver add or remove references to each other to the Binder relationship structure of the cgroup module through the cross-module calling interface, and the secondary linked list structure is updated in real time.

[0161] Optionally, the relationship synchronization module further includes:

[0162] The first synchronization unit is used to synchronize the reference relationship to the Binder relationship structure of the cgroup module through the cross-module call interface when the processes at both ends of the communication are disconnected and the reference is removed in the Binder driver, so that the secondary linked list structure is updated in real time.

[0163] Optionally, the device further comprises:

[0164] A first optimization module, configured to, in response to the client proxy linked list in the Binder relationship structure not existing, create a client proxy and add it to the Binder relationship structure, and simultaneously create a server proxy and add it to the client proxy;

[0165] A second optimization module is used for, in response to the existence of the client proxy linked list in the Binder relationship structure, traversing the client proxy linked list and searching whether a corresponding client proxy exists; if the client proxy does not exist, creating a client proxy and adding it to the Binder relationship structure, and creating a server proxy and adding it to the client proxy;

[0166] The third optimization module is used to search whether there is a corresponding server proxy in the server proxy list in response to the existence of both the client proxy list and the client proxy. If the server proxy does not exist, a server proxy is created and added to the client proxy in the server proxy list. If the server proxy exists, a reference count of the server proxy is increased.

[0167] Optionally, when at least two binder communication relationships exist simultaneously between the processes where the client and the server are located, the device further includes:

[0168] A fourth optimization module, used to remove redundant connections and reference relationships between the two ends of the binder communication through the cross-module call interface, and synchronize the reference relationship between the two ends of the binder communication to the cgroup module;

[0169] A fifth optimization module, used to extract messages from the client and the server through the cgroup module;

[0170] The sixth optimization module is used to determine whether the client proxy linked list of the Binder relationship structure exists. If not, the process is terminated; if the client proxy linked list of the Binder relationship structure exists, the client proxy linked list is traversed to determine whether there is a corresponding client proxy;

[0171] A seventh optimization module, for terminating the process if the corresponding client agent does not exist, and for determining whether the corresponding server agent exists in the client agent linked list where the client agent is located if the corresponding client agent exists;

[0172] The eighth optimization module is used to end the process if the corresponding server agent does not exist, and if the corresponding server agent exists, reduce the reference count of the corresponding server agent until it is reduced to 1 and then remove the server agent linked list corresponding to the client agent.

[0173] Optionally, the synchronization adjustment module includes:

[0174] A first adjustment unit, used for the client resource group of the Binder communication to change, wherein the client sends a synchronization message to the server, and the client process runs and starts to execute binder_transaction;

[0175] A second adjustment unit is used for the thread of the server to start reading the synchronization message to execute binder_thread_read, and synchronize the reference relationship to the cgroup module through the cross-module call interface;

[0176] A third adjustment unit is used to migrate the server process to the resource group to which the client belongs in the cgroup module according to the reference relationship between the client and the server, and save the resource group to which the server previously belonged;

[0177] A fourth adjustment unit, configured for the server to provide feedback on the synchronization message by executing binder_transaction;

[0178] The fifth adjustment unit is used to run to the cgroup module through the cross-module call interface in the binder_transaction feedback process;

[0179] The sixth adjustment unit is used to migrate the server process from the resource group to which the current client belongs to the resource group to which the server previously belonged in the cgroup module by adopting the cgroup group migration method.

[0180] Optionally, in the cgroup module, the third adjustment unit is further used to:

[0181] Add the pointer *restoreCgroups of the css_set structure to the server thread structure;

[0182] Save the css_set structure corresponding to the server thread structure to *restoreCgroups, and traverse the client cgrp_links list to obtain each cgroup group to which it belongs;

[0183] Use cgroup_attach_task to migrate the server thread structure to each cgroup group to which each client thread belongs.

[0184] Optionally, in the cgroup module, the sixth adjustment unit is further used to:

[0185] Get the pointer *restoreCgroups of the css_set structure saved by the server thread structure, traverse the server cgrp_links list to get each cgroup group to which it belongs, and use cgroup_attach_task to migrate the server thread structure to each cgroup group to which each server thread previously belonged.

[0186] Each module in the above-mentioned inter-process communication related resource optimization device can be implemented in whole or in part by software, hardware and their combination. Each of the above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the corresponding operations of each of the above modules.

[0187] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0188] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A method for optimizing inter-process communication related resources, characterized in that: The method comprises: The reference relationship between the processes at both ends of the Binder communication is synchronized to the cgroup module through a cross-module call interface, wherein the two ends of the Binder communication include the client and the server; According to the reference relationship, a related server is synchronously adjusted when a client resource group of Binder communication changes, wherein the client resource group refers to a resource management unit to which the client application belongs; For the Binder communication process of the client resource group that is not synchronized, synchronize the changes of the client resource group to the server when synchronous communication occurs; After the Binder communication process is completed, the server resource group is restored, and all Binder communication-related processes are included in the management to achieve optimal allocation of related resources.

2. The method according to claim 1, characterized in that When the cgroup module is started early, a Binder relationship structure is added. The Binder relationship structure adopts a two-level linked list structure, the first level is a client proxy linked list, and the second level is a server proxy linked list; Among them, the client proxy linked list is used to store the proxy information of all client processes, the server proxy linked list is used to store the proxy information of all server processes, and the Binder relationship structure is used to manage the reference relationship of the Binder communication through the secondary linked list structure.

3. The method according to claim 2, characterized in that The reference relationship between processes at both ends of Binder communication is synchronized to the cgroup module through a cross-module calling interface, including: The reference relationship when the processes at both ends of the communication in the Binder driver add or remove references to each other is synchronized to the Binder relationship structure of the cgroup module through the cross-module calling interface, and the secondary linked list structure is updated in real time.

4. The method according to claim 2, characterized in that: The reference relationship between the processes at both ends of the Binder communication is synchronized to the cgroup module through the cross-module calling interface, and further includes: When the processes at both ends of the communication are disconnected and the reference is removed in the Binder driver, the reference relationship is synchronized to the Binder relationship structure of the cgroup module through the cross-module call interface, and the secondary linked list structure is updated in real time.

5. The method according to claim 3, characterized in that: The method further comprises: In response to the client proxy linked list in the Binder relationship structure not existing, creating a client proxy and adding it to the Binder relationship structure, and creating a server proxy and adding it to the client proxy; In response to the existence of the client proxy linked list in the Binder relationship structure, traverse the client proxy linked list and find whether there is a corresponding client proxy. If the client proxy does not exist, create a client proxy and add it to the Binder relationship structure, and create a server proxy and add it to the client proxy. In response to the existence of both the client proxy linked list and the client proxy, a search is performed to determine whether a corresponding server proxy exists in the server proxy linked list. If the server proxy does not exist, a server proxy is created and added to the client proxy in the server proxy linked list. If the server proxy exists, a reference count of the server proxy is increased.

6. The method according to any one of claims 1 to 5, characterized in that: When at least two binder communication relationships exist simultaneously between the processes where the client and the server are located, the method further includes: Remove redundant connections and reference relationships between the two ends of the binder communication through the cross-module calling interface, and synchronize the reference relationship between the two ends of the binder communication to the cgroup module; Extracting messages from the client and the server through the cgroup module; Determine whether the client proxy linked list of the Binder relationship structure exists. If not, end the process; if the client proxy linked list of the Binder relationship structure exists, traverse the client proxy linked list to determine whether there is a corresponding client proxy; If the corresponding client agent does not exist, the process ends; if the corresponding client agent exists, it is determined whether there is a corresponding server agent in the client agent linked list where the client agent is located; If the corresponding server agent does not exist, the process ends; if the corresponding server agent exists, the reference count of the corresponding server agent is reduced until it is reduced to 1, and then the server agent linked list corresponding to the client agent is removed.

7. The method according to claim 2, characterized in that The synchronous adjustment of the relevant server when the client resource group of Binder communication changes according to the reference relationship includes: When the client resource group of the Binder communication changes, the client sends a synchronization message to the server, and the client process runs and starts to execute binder_transaction; The thread of the server starts to read the synchronization message to execute binder_thread_read, and synchronizes the reference relationship to the cgroup module through the cross-module call interface; In the cgroup module, according to the reference relationship between the client and the server, the cgroup group migration method is adopted to migrate the server process to the resource group to which the client belongs, and the resource group to which the server previously belonged is saved; The server provides feedback for the synchronization message by executing binder_transaction; In the binder_transaction feedback process, the interface is called across modules and runs to the cgroup module; In the cgroup module, the cgroup group migration method is adopted to perform migration, and the server process is moved from the resource group to which the current client belongs to the resource group to which the server previously belonged.

8. The method for optimizing resource allocation of binder-related processes according to claim 7, characterized in that: In the cgroup module, migration is performed using a cgroup group migration method, including: Add the pointer *restoreCgroups of the css_set structure to the server thread structure; Save the css_set structure corresponding to the server thread structure to *restoreCgroups, and traverse the client cgrp_links list to obtain each cgroup group to which it belongs; Use cgroup_attach_task to migrate the server thread structure to each cgroup group to which each client thread belongs.

9. The method for optimizing resource allocation of binder-related processes according to claim 7, characterized in that: In the cgroup module, the cgroup group migration method is used for migration, including: Get the pointer *restoreCgroups of the css_set structure saved by the server thread structure, traverse the server cgrp_links list to get each cgroup group to which it belongs, and use cgroup_attach_task to migrate the server thread structure to each cgroup group to which each server thread previously belonged.

10. A device for optimizing resources related to inter-process communication, characterized in that: The device comprises: A relationship synchronization module is used to synchronize the reference relationship of processes at both ends of Binder communication to the cgroup module through a cross-module call interface, wherein the two ends of the Binder communication include the client and the server; A synchronization adjustment module, used for synchronously adjusting the relevant server when the client resource group of Binder communication changes according to the reference relationship, wherein the client resource group refers to the resource management unit to which the client application belongs; A change synchronization module, for synchronizing the changes of the client resource group to the server when synchronous communication occurs for the Binder communication process of the client resource group that is not synchronized; The optimization allocation module is used to restore the server resource group after the Binder communication process is completed. All the Binder communication related processes are included in the management to achieve the optimization allocation of related resources.

Images