Cooperative management method and system of GPU display memory and system memory of cloud mobile phone platform

Abstract

The application provides a GPU display memory and system memory cooperative management method and system of a cloud mobile platform, the method comprising: acquiring GPU display memory parameters of the GPU display memory and system memory parameters of the system memory of the cloud mobile platform in real time, and calculating a resource imbalance index and a unified stress value according to the GPU display memory parameters and the system memory parameters; constructing a unified resource view according to the GPU display memory parameters, the system memory parameters, the unified stress value and the resource imbalance index, and making corresponding cooperative scheduling decisions for the GPU display memory and / or the system memory based on the unified resource view; detecting a current session state of a user, adopting a corresponding resource allocation strategy according to the current session state, and adjusting resource allocation of the GPU display memory and the system memory through a resource smooth switching mechanism when the session state of the user is switched; and predicting an application to be started by the user based on historical behaviors of the user, and performing resource pre-allocation processing on the application to be started. The application can realize cooperative scheduling of the GPU display memory and the system memory.

Description

Technical Field

[0001] This invention belongs to the field of cloud phone technology, and in particular relates to a method and system for the collaborative management of GPU memory and system memory in a cloud phone platform. Background Technology

[0002] Cloud phone platforms allow users to remotely access and use Android system instances running in the cloud. Typical application scenarios include cloud gaming platforms (such as Tencent Start and NetEase Cloud Games), cloud phone platforms (such as Palm Cloud Phone and Huawei Cloud Phone), and mobile application automated testing platforms (such as Testin and TestBird).

[0003] Among them, the existing cloud mobile phone platform scenarios have the following significant characteristics: (1) Sharing and competition of GPU graphics buffer: Each cloud phone instance needs to perform graphics rendering through GPU. The graphics buffer usually occupies 200-800MB. When multiple containers share the physical GPU, GPU memory competition and rendering queue congestion will occur.

[0004] (2) Persistence and continuity of user sessions: When users connect to the same cloud phone instance for a long time (several hours or even several days), the Activity stack, background Service, and application state need to be persistently saved.

[0005] However, existing cloud phone platform technologies have the following drawbacks: Defect 1: Disconnect between GPU memory and system memory management Current technology treats GPU memory management and system memory management as two separate issues, lacking coordinated scheduling. This results in situations where GPU memory is insufficient but system memory is ample, and vice versa. Real-world testing with PalmCloud Phone shows that when running graphics-intensive games (such as Genshin Impact), GPU memory usage reaches 95%, but system memory usage is only 60%, causing the game frame rate to drop from 60 FPS to 25 FPS. Defect 2: The complexity and multi-dimensional constraints of co-optimization between GPU memory and system memory The coordinated optimization of GPU memory and system memory in cloud phone scenarios faces complex constraints across multiple dimensions: diverse application types (GPU-intensive for games, memory-intensive for video, and relatively balanced for social applications), dynamic user behavior (rapid switching between foreground / background / offline), and strict hardware constraints (50-100 instances per machine, 8-16GB GPU memory, and 64-128GB system memory). Real-world testing by PalmPai Cloud Phone shows that these multi-dimensional constraints make the coordinated optimization of GPU memory and system memory a highly complex nonlinear optimization problem.

[0006] Defect 3: Lack of user session awareness, unreasonable timing of session state collection, and difficulty in guaranteeing the real-time performance and accuracy of session state awareness. Cloud phones need to accurately sense user session status (online foreground / background / idle / offline). However, current technology cannot sense user session status, leading to memory reclamation during active user periods, causing lag and application state loss; memory is not actively reorganized when users are offline, resulting in resource waste; and state transitions are delayed (resource adjustments take 10-30 seconds). Real-world testing by PalmPai Cloud Phone shows that 20% of memory reclamation occurs during active user periods, resulting in a user complaint rate as high as 15%; while during offline periods (accounting for 60% of the time), only 30% of memory reorganization is performed. Summary of the Invention

[0007] This invention provides a method for the collaborative management of GPU memory and system memory on a cloud phone platform, aiming to solve at least one of the technical problems mentioned in the background art.

[0008] This invention is implemented as follows: a method for the collaborative management of GPU memory and system memory in a cloud phone platform, comprising: The system acquires the GPU memory parameters and system memory parameters of the cloud phone platform in real time, and calculates the resource imbalance index and unified pressure value based on the GPU memory parameters and system memory parameters. The resource imbalance index is used to characterize the difference in the utilization rate of the GPU memory and the system memory, and the unified pressure value is used to characterize the pressure status of the GPU memory and the system memory. A unified resource view is constructed based on the GPU memory parameters, the system memory parameters, the unified stress value, and the resource imbalance index. Based on the unified resource view, corresponding collaborative scheduling decisions are made on the GPU memory and / or the system memory. The collaborative scheduling decisions are used to at least adjust the size of the GPU memory and / or the system memory. The system detects the user's current session state and adopts a corresponding resource allocation strategy based on this state. When the user's session state changes, a resource smoothing mechanism adjusts the resource allocation between the GPU memory and system memory. Different session states correspond to different resource allocation strategies. These strategies adjust at least one of the following: system CPU quota, GPU memory quota, system memory quota, and encoding quality. The resource smoothing mechanism smoothly switches between the GPU memory and system memory. Based on the user's historical behavior, the system predicts the applications the user is about to launch and performs resource pre-allocation for those applications to reduce application startup delays.

[0009] In one embodiment, the collaborative management method further includes: Create independent channels for the graphics buffer and video encoding buffer of the cloud phone platform, and set minimum memory values ​​and memory warning thresholds for the independent channels; The video encoding buffer is locked using the mlock mechanism; The buffer configuration of the graphics buffer is dynamically adjusted based on the current session state; The buffer configuration of the video encoding buffer is dynamically adjusted according to the current network conditions; Targeted optimizations were performed on the Zygote process, Ashmem region, and Binder buffer of the cloud phone platform. The resource usage and average resource usage of each container on the cloud phone platform are obtained, and the deviation coefficient of each container is calculated. Based on the magnitude of the deviation coefficient, the resource quota and memory reclamation frequency of the containers are adjusted. Each container includes the system CPU, the GPU memory, and the system memory. Monitor the resource growth rate of each container and adjust the resource quota of the container according to the magnitude of the resource growth rate.

[0010] In one embodiment, the GPU memory parameters include total GPU memory, GPU memory usage, and GPU memory utilization rate; the system memory parameters include total system memory, system memory usage, and system memory utilization rate; and the calculation of the resource imbalance index and unified pressure value based on the GPU memory parameters and the system memory parameters includes: The GPU memory utilization rate is calculated based on the total amount of GPU memory and the amount of GPU memory used. Obtain the first set parameter, and calculate the resource imbalance index based on the GPU memory usage rate, the system memory usage rate and the first set parameter; The system memory utilization rate is calculated based on the total system memory and the system memory usage; and Obtain the GPU weight coefficient, memory weight coefficient, and a second set parameter; calculate a unified pressure value based on the GPU memory usage rate, the GPU weight coefficient, the system memory usage rate, the memory weight coefficient, the resource imbalance index, and the second set parameter. Wherein, the first setting parameter is half of the second setting parameter, and the sum of the GPU weight coefficient and the memory weight coefficient is equal to 1.

[0011] In one embodiment, the collaborative scheduling decision includes not triggering scheduling, triggering scheduling to migrate inactive GPU textures from the GPU memory to the system memory, triggering scheduling to compress compressible data in the system memory, triggering collaborative reclamation scheduling, and triggering emergency degradation scheduling. The step of making corresponding collaborative scheduling decisions for the GPU memory and / or the system memory based on the unified resource view includes: Determine the magnitude of the unified pressure value, the status of the GPU memory, the status of the system memory, and the magnitude of the resource imbalance index in the unified resource view; When the unified pressure value is within the first set range, the GPU memory is in a normal state, and the system memory is in a normal state, scheduling is not triggered for the GPU memory and the system memory. When the unified pressure value is within the second set range, the GPU memory is under pressure, the system memory is sufficient, and the resource imbalance index is less than the resource threshold, the inactive GPU textures in the GPU memory are migrated to the system memory for scheduling. When the unified pressure value is within the second set range, the GPU memory is in a sufficient state, the system memory is in a tense state, and the resource imbalance index is less than the resource threshold, the compressible data in the system memory is compressed and scheduled. When the unified pressure value is within a third preset range, and the GPU memory or the system memory is in a critical state, a coordinated reclamation scheduling is triggered for the GPU memory and the system memory; and When the unified pressure value is within the fourth set range and both the GPU memory and the system memory are in a critical state, an emergency degradation scheduling is triggered for the GPU memory and the system memory.

[0012] In one embodiment, migrating inactive GPU textures from the GPU memory to the system memory includes: Identify inactive GPU textures in the GPU memory; Migrate inactive GPU textures from the GPU memory to the system memory; and The inactive GPU texture is maintained in the system memory. When the inactive GPU texture is accessed again, it is delayed for a set time before being loaded back into the GPU memory. The triggering of system memory data compression includes: Identify compressible memory data in system memory; The compressible memory data is compressed using a GPU-accelerated compression algorithm; and The compressed compressible data is stored in system memory; The triggering of collaborative recycling includes: Identify inactive GPU textures in the GPU memory and migrate the inactive GPU textures to the system memory; Identify compressible data in the system memory and compress the compressible data using a GPU-accelerated algorithm; and Trigger system memory reclamation; The triggering of emergency downgrade includes: Reduce the video encoding quality of the cloud phone platform; Reduce the GPU memory allocation; Lower the system memory level; and Trigger aggressive memory reclamation.

[0013] In one embodiment, the session state includes a first session state, a second session state, a third session state, and a fourth session state; the resource allocation strategy includes a first allocation strategy, a second allocation strategy, a third allocation strategy, and a fourth allocation strategy; and the step of detecting the user's current session state and adopting a corresponding resource allocation strategy based on the current session state includes: If a user is detected to be online and using a cloud phone platform, the user's current session state is determined to be the first session state, and a first allocation strategy corresponding to the first session state is adopted. The first allocation strategy is: setting the system CPU quota to 100%, the GPU memory quota to 100%, the system memory quota to normal level, and the encoding quality to high quality. If a user is detected to be online but the application is running in the background, the user's current session state is determined to be the second session state, and a second allocation strategy corresponding to the second session state is adopted. The second allocation strategy is: setting the system CPU quota to a first set value, setting the GPU memory quota to a second set value, setting the system memory quota to an increased level, and setting the encoding quality to medium quality. The first set value is greater than the second set value and less than 1. If a user is detected to be online but the cloud phone platform is idle, the user's current session state is determined to be a third session state, and a third allocation strategy corresponding to the third session state is adopted. The third allocation strategy is as follows: setting the system CPU quota to a second preset value, setting the GPU memory quota to a third preset value, setting the system memory quota to aggressive reclamation, and setting the encoding quality to low quality, wherein the third preset value is less than the second preset value; and If a user is detected to be offline, the user's current session state is determined to be the fourth session state, and a fourth allocation strategy corresponding to the fourth session state is adopted. The fourth allocation strategy is: setting the system CPU quota to the third set value, setting the GPU memory quota to 0, and setting the system memory quota to the minimum level and stopping encoding.

[0014] In one embodiment, the smooth switching mechanism includes a first set duration for delayed confirmation of switching, a step size setting range for gradual adjustment, and a second set duration for reserving the GPU memory and / or the system memory resources, wherein the second set duration is at least twice the first set duration. The resource pre-allocation includes cold start optimization, texture preloading, service preheating, and network pre-connection. The cold start optimization is to pre-incubate the application's startup process in advance. The texture preloading is to load the GPU texture corresponding to the application into the GPU memory in advance. The service preheating is to start the services required by the application in advance. The network pre-connection is to establish a network connection between the application and the server in advance.

[0015] In one embodiment, the session state includes a first session state, a second session state, and a third session state, and the step of dynamically adjusting the buffer configuration of the graphics buffer according to the current session state includes: If the user's current session state is the first session state, the graphics buffer is adjusted to a triple buffer configuration; if the user's current session state is the second session state, the graphics buffer is adjusted to a double buffer configuration; if the user's current session state is the third session state, the graphics buffer is adjusted to a single buffer configuration. The network conditions include network bandwidth and whether the network is switching. The step of dynamically adjusting the buffer configuration of the video encoding buffer based on the current network conditions includes: If the current network bandwidth is greater than the first bandwidth value, the encoding quality and buffer size of the video encoding buffer are increased; if the current network bandwidth is less than the second bandwidth value, the encoding quality and buffer size of the video encoding buffer are decreased; if the current network switches, the buffer size of the video encoding buffer is adjusted. The specific optimizations performed on the Zygote process, Ashmem region, and Binder buffer of the cloud phone platform include: Identify shared memory pages in the Zygote process, and when calculating the resource usage of the container, perform deduplication statistics on the shared memory pages and mark the shared memory pages as non-reclaimable; Each Ashmem region is referenced and counted. When the count is 0, the corresponding Ashmem region is reclaimed. The Ashmem region is prioritized according to its usage. When reclaiming, the Ashmem region with lower priority is reclaimed first. The usage of the Binder buffer is monitored. When the usage rate of the Binder buffer exceeds a first set usage rate, it is determined that the Binder buffer is under pressure and an early warning is triggered. When the usage rate of the Binder buffer is greater than a second set usage rate, the Binder buffer is pre-allocated. When the pressure on the Binder buffer is greater than a set pressure, non-critical calls to the Binder buffer are rate-limited. The second set usage rate is greater than the first set usage rate.

[0016] In one embodiment, adjusting the container's resource quota and memory reclamation frequency based on the magnitude of the deviation coefficient includes: When the deviation coefficient of the container is greater than the first coefficient threshold, the resource quota of the container is reduced and the memory reclamation frequency is increased; When the deviation coefficient of the container is less than the second coefficient threshold, the resource quota of the container is increased and the memory reclamation frequency is reduced; The step of adjusting the resource quota of the container according to the resource growth rate includes: When the resource growth rate is greater than the first growth rate threshold, the corresponding container is determined to be abnormal, and the resource quota of the container determined to be abnormal is adjusted to the minimum. When the resource growth rate exceeds the second growth rate threshold, the corresponding container is determined to be severely abnormal, and the container determined to be severely abnormal is restarted.

[0017] This invention also provides a collaborative management system for GPU memory and system memory on a cloud phone platform, including: The calculation module is used to obtain the GPU memory parameters of the GPU memory and the system memory parameters of the system memory of the cloud phone platform in real time, and calculate the resource imbalance index and the unified pressure value based on the GPU memory parameters and the system memory parameters. The resource imbalance index is used to characterize the difference in the utilization rate of the GPU memory and the system memory, and the unified pressure value is used to characterize the pressure status of the GPU memory and the system memory. The scheduling module is used to construct a unified resource view based on the GPU memory parameters, the system memory parameters, the unified pressure value and the resource imbalance index, and to make corresponding collaborative scheduling decisions on the GPU memory and / or the system memory based on the unified resource view. The collaborative scheduling decisions are used to at least adjust the size of the GPU memory and / or the system memory. The allocation module is used to detect the user's current session state and adopt a corresponding resource allocation strategy based on the current session state. When the user's session state changes, a resource smoothing switching mechanism is used to adjust the resource allocation of the GPU memory and the system memory. Different session states correspond to different resource allocation strategies. The resource allocation strategy is used to adjust at least one of the system CPU quota, GPU memory quota, system memory quota, and encoding quality. The resource smoothing switching mechanism is used to smoothly switch the GPU memory and system memory. The processing module is used to predict the application that the user is about to launch based on the user's historical behavior, and to perform resource pre-allocation processing on the application to be launched. The resource pre-allocation processing is used to reduce application startup delay.

[0018] The collaborative management method of GPU memory and system memory of the cloud mobile phone platform in this invention has the following beneficial effects: ① Compared to existing technologies that manage GPU memory and system memory separately, resulting in uneven resource utilization and other drawbacks, this invention calculates a resource imbalance index and a unified pressure value using GPU memory parameters and system memory parameters. This index characterizes the difference in usage and pressure between GPU memory and system memory, accurately identifying resource imbalance and pressure changes. Furthermore, a unified resource view is constructed based on GPU memory parameters, system memory parameters, unified pressure value, and resource imbalance index. Based on this unified resource view, coordinated scheduling and optimization of GPU memory and system memory are achieved, effectively improving resource utilization and making resource utilization more balanced.

[0019] ② Compared to existing technologies that cannot perceive the user's session state, leading to a decline in user experience due to potential resource reclamation during active user activity, this invention employs a session-aware mechanism to adopt differentiated resource allocation strategies for different session states. This matches resource allocation with the user's actual usage, effectively improving the user experience. Furthermore, when the user's session state changes, a smooth resource switching mechanism adjusts the resource allocation of GPU memory and system memory, seamlessly switching between them and avoiding the abrupt changes in user experience caused by traditional "one-step" resource adjustments.

[0020] In addition, by predicting the applications that users are about to launch based on their historical behavior and pre-allocating resources for those applications, the startup latency of the applications is effectively reduced, and the user experience is significantly improved. Attached Figure Description

[0021] Figures 1 to 5This is a flowchart illustrating the collaborative management method of GPU memory and system memory for a cloud phone platform provided in this embodiment of the invention. Figure 6 and Figure 7 This is a schematic diagram of the structure of the collaborative management system for GPU memory and system memory of the cloud mobile phone platform provided in this embodiment of the invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the invention, and should not be construed as limiting the invention. Furthermore, it should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0023] In the description of this invention, it should be understood that the orientation or positional relationship indicated in the description of direction and positional relationship is based on the orientation or positional relationship shown in the drawings, and is only for the convenience of describing this invention and simplifying the description, and is not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

[0024] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0025] The following disclosure provides many different embodiments or examples for implementing different structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. Of course, these are merely examples and are not intended to limit the invention.

[0026] Furthermore, the present invention may repeat reference numerals and / or reference letters in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or settings discussed. In addition, the present invention provides examples of various specific processes and materials, but those skilled in the art will recognize the application of other processes and / or the use of other materials.

[0027] Please see Figure 1The method for collaborative management of GPU memory and system memory in a cloud phone platform according to an embodiment of the present invention includes the following steps: S11: Real-time acquisition of GPU memory parameters and system memory parameters of the cloud phone platform, and calculation of resource imbalance index and unified pressure value based on GPU memory parameters and system memory parameters. Resource imbalance index is used to characterize the difference in utilization rate between GPU memory and system memory, and unified pressure value is used to characterize the pressure status of GPU memory and system memory.

[0028] In this embodiment of the invention, the cloud phone platform runs on the Android system. The resources of the physical container of the cloud phone platform include CPU resources, GPU memory resources and system memory resources. The resource adjustment and allocation processes mentioned in this embodiment of the invention refer to the adjustment and allocation of CPU resources, GPU memory resources and / or system memory resources.

[0029] To achieve coordinated management of GPU memory and system memory, the parameters of GPU memory and system memory are first obtained. The GPU memory parameters can include at least the total amount of GPU memory and the amount of GPU memory used, so as to provide real-time feedback on the usage of GPU memory. The system memory parameters can include at least the total amount of system memory and the amount of system memory used, so as to provide real-time feedback on the usage of system memory.

[0030] Furthermore, the resource imbalance index and unified pressure value are calculated based on the GPU memory parameters and system memory parameters. The resource imbalance index is used to measure the difference in the utilization rate of GPU memory and system memory, while the unified pressure value is used to comprehensively consider the pressure status of GPU memory and system memory. In this way, the actual usage of GPU memory and system memory can be accurately reflected through the resource imbalance index and unified pressure value.

[0031] S12: Construct a unified resource view based on GPU memory parameters, system memory parameters, unified stress value and resource imbalance index, and make corresponding collaborative scheduling decisions on GPU memory and / or system memory based on the unified resource view. The collaborative scheduling decisions are used to at least adjust the size of GPU memory and / or system memory.

[0032] The constructed Unified Resource View includes fields such as GPU memory parameters, system memory parameters, unified stress value, and resource imbalance index. It can clearly display various parameters, usage differences, and stress status of GPU memory and system memory, thereby facilitating accurate collaborative scheduling decisions for GPU memory and / or system memory. The collaborative scheduling decisions correspond to the Unified Resource View and are used to balance the imbalance and stress status between GPU memory and system memory.

[0033] S13: Detect the user's current session state and adopt the corresponding resource allocation strategy according to the current session state. When the user's session state changes, adjust the resource allocation of GPU memory and system memory through the resource smooth switching mechanism. Different session states correspond to different resource allocation strategies. The resource allocation strategy is used to adjust at least one of the system CPU quota, GPU memory quota, system memory quota and encoding quality. The resource smooth switching mechanism is used to smoothly switch GPU memory and system memory.

[0034] Specifically, the user's current session state can be detected by detecting the user's online / offline status (e.g., monitoring WebSocket and RDP connections), detecting foreground applications (e.g., through the ActivityManager service), and detecting user interaction status (e.g., by monitoring touch events and keyboard events). The session state can include foreground usage status, background usage status, idle status, and offline status.

[0035] Subsequently, different resource allocation strategies are adopted for different session states to dynamically adjust CPU quotas, system memory quotas, GPU memory quotas, and / or video encoding quality, ensuring a high-quality experience for active users and actively releasing resources when offline. To avoid impacting user experience from resource adjustments, a smooth resource segment switching mechanism is introduced, making changes to resource allocation gradual and controllable.

[0036] S14: Based on the user's historical behavior, predict the application that the user is about to launch, and perform resource pre-allocation processing on the application to be launched. Resource pre-allocation processing is used to reduce application startup delay.

[0037] Through a user behavior prediction mechanism, the platform can anticipate the applications a user is about to launch based on their historical behavior and pre-allocate resources, thereby significantly reducing application launch latency. The user's historical behavior can include frequently used times on the cloud phone platform, frequently used applications, and historical operation sequences. The historical operation sequence refers to the order in which the user performs actions while using the cloud phone platform, such as application launch order and function usage order.

[0038] The collaborative management method of GPU memory and system memory of the cloud mobile phone platform in this invention has the following beneficial effects: ① Compared to existing technologies that manage GPU memory and system memory separately, resulting in uneven resource utilization and other drawbacks, this invention calculates a resource imbalance index and a unified pressure value using GPU memory parameters and system memory parameters. This index characterizes the difference in usage and pressure between GPU memory and system memory, accurately identifying resource imbalance and pressure changes. Furthermore, a unified resource view is constructed based on GPU memory parameters, system memory parameters, unified pressure value, and resource imbalance index. Based on this unified resource view, coordinated scheduling and optimization of GPU memory and system memory are achieved, effectively improving resource utilization and making resource utilization more balanced.

[0039] ② Compared to existing technologies that cannot perceive the user's session state, leading to a decline in user experience due to potential resource reclamation during active user activity, this invention employs a session-aware mechanism to adopt differentiated resource allocation strategies for different session states. This matches resource allocation with the user's actual usage, effectively improving the user experience. Furthermore, when the user's session state changes, a smooth resource switching mechanism adjusts the resource allocation of GPU memory and system memory, seamlessly switching between them and avoiding the abrupt changes in user experience caused by traditional "one-step" resource adjustments.

[0040] In addition, by predicting the applications that users are about to launch based on their historical behavior and pre-allocating resources for those applications, the startup latency of the applications is effectively reduced, and the user experience is significantly improved.

[0041] In one embodiment of the present invention, GPU memory parameters include total GPU memory, GPU memory usage, and GPU memory utilization rate; system memory parameters include total system memory, system memory usage, and system memory utilization rate. Please refer to [link to relevant documentation]. Figure 2 In step S11, the step of calculating the resource imbalance index and unified pressure value based on the GPU memory parameters and system memory parameters includes the following steps: S111: The GPU memory utilization rate is calculated based on the total amount of GPU memory and the amount of GPU memory used.

[0042] Among them, GPU memory utilization rate = GPU memory usage / total GPU memory.

[0043] S112: Obtain the first set parameter, and calculate the resource imbalance index based on the GPU memory usage rate, system memory usage rate and the first set parameter.

[0044] Specifically, imbalance = |gpu_usage_ratio - mem_usage_ratio| × a, where imbalance is the resource imbalance index, gpu_usage_ratio is the GPU memory usage rate, mem_usage_ratio is the system memory usage rate, and a is the first set parameter.

[0045] When the resource imbalance index exceeds the imbalance threshold, that is, when the difference between the usage rate of GPU memory and system memory exceeds a certain proportion, it is determined that there is a resource imbalance between GPU memory and system memory, and a resource migration mechanism needs to be triggered.

[0046] In one embodiment, the first set parameter is 100, and the imbalance threshold is 50%.

[0047] S113: The system memory utilization rate is calculated based on the total system memory and the system memory usage.

[0048] System memory utilization rate = system memory usage / total system memory.

[0049] S114: Obtain the GPU weight coefficient, memory weight coefficient and second setting parameter. Calculate a unified pressure value based on GPU memory usage, GPU weight coefficient, system memory usage, memory weight coefficient, resource imbalance index and second setting parameter. The first setting parameter is half of the second setting parameter, and the sum of the GPU weight coefficient and memory weight coefficient is equal to 1.

[0050] Specifically, unified_pressure = b × gpu_pressure + c × mem_pressure + imbalance / d, where unified_pressure is the unified pressure value, b is the GPU weight coefficient, gpu_pressure is the GPU memory usage rate, c is the memory weight coefficient, mem_pressure is the system memory usage rate, and d is a second set parameter, where both the GPU memory usage rate and the system memory usage rate are between 0 and 1.

[0051] In one embodiment, the GPU weight coefficient is 0.6, the memory weight coefficient is 0.4, and the second set parameter is 200.

[0052] It should be noted that the GPU weight coefficient of 0.6 and the memory weight coefficient of 0.4 are the optimal values ​​obtained by this invention through large-scale field tests on the Palm Cloud Phone Platform (covering 100+ application types and 10,000+ user sessions). These values ​​improve resource utilization by 15% compared to the equal weight configuration (i.e., both are 0.5) and by 30% compared to the traditional separate management scheme.

[0053] In one embodiment of the present invention, the cooperative scheduling decision includes not triggering scheduling, triggering scheduling to migrate inactive GPU textures from GPU memory to system memory, triggering scheduling to compress compressible data in system memory, triggering cooperative reclamation scheduling, and triggering emergency degradation scheduling. Please refer to [link to relevant documentation]. Figure 3 In step S11, the step of making corresponding collaborative scheduling decisions on GPU memory and / or system memory based on the unified resource view includes the following steps: S115: Determine the magnitude of the unified stress value, the status of the GPU memory, the status of the system memory, and the magnitude of the resource imbalance index in the unified resource view.

[0054] The magnitude of the unified pressure value and the resource imbalance index can be directly confirmed in the unified resource view. The status / pressure of GPU memory and system memory can be confirmed by the GPU memory usage rate and system memory usage rate. When the usage rate reaches different ranges or magnitudes, it indicates different states / pressures of GPU memory and system memory.

[0055] For example, when the usage rates of GPU memory and system memory reach 0%~20%, 20%~40%, 40%~60%, 60%~80%, 80%~90% / 100%, or 0%~30%, 30%~60%, 60%~90%, 90%~100%, these correspond to different usage states and storage pressures of GPU memory and system memory.

[0056] The above description of the usage range of GPU memory and system memory is merely illustrative and should not be construed as a limitation on the embodiments of the present invention. Specific usage ranges can be designed in actual applications.

[0057] S116: When the unified pressure value is within the first set range, the GPU memory is in a normal state, and the system memory is in a normal state, scheduling of the GPU memory and system memory will not be triggered.

[0058] The first set range is a small or moderate value range. At this time, both GPU memory and system memory are used normally, and the storage resources of the cloud phone platform are used less. Therefore, there is no need to coordinate the scheduling of GPU memory and system memory, and normal operation is sufficient.

[0059] S117: When the uniform pressure value is within the second set range, the GPU memory is under pressure, the system memory is sufficient, and the resource imbalance index is less than the resource threshold, the inactive GPU textures in the GPU memory are migrated to the system memory for scheduling.

[0060] The second set range is larger than the first set range, which is a relatively large numerical range. This indicates that the unified pressure value is relatively large at this time, and the resource pressure on GPU memory or system memory is relatively large. If it is detected that the resource usage of GPU memory is relatively high and in a tense state, while the resource usage of system memory is relatively low and in a sufficient state, and the resource imbalance index is less than the resource threshold, it indicates that the resource usage of GPU memory and system memory is unbalanced at this time (the usage pressure of GPU memory is high), and the two need to be coordinated and scheduled.

[0061] At this point, since inactive GPU textures indicate that the user does not need to use them temporarily, inactive GPU textures in the GPU memory can be migrated to system memory to relieve the pressure on the GPU memory, promote overall resource balance, and thus ensure normal use by the user.

[0062] S118: When the unified pressure value is within the second set range, the GPU memory is in a sufficient state, the system memory is in a tense state, and the resource imbalance index is less than the resource threshold, the system memory is triggered to compress and schedule the compressible data in the system memory.

[0063] If the GPU memory usage is relatively low and in a state of abundance, while the system memory usage is relatively high and in a state of strain, and the resource imbalance index is less than the resource threshold, it indicates that the GPU memory and system memory resources are unbalanced (the system memory is under great pressure), and coordinated scheduling between the two is required.

[0064] At this point, compressible data in system memory is compressed to reduce system memory pressure, promote overall resource balance, and thus ensure normal user operation.

[0065] S119: When the unified pressure value is within the third set range and the GPU memory or system memory is in a critical state, trigger a coordinated recycling schedule for the GPU memory and system memory.

[0066] The third setting range is larger than the second setting range, which is a larger numerical range. This means that the unified pressure value is larger at this time, indicating that the resource pressure of GPU memory or system memory is large, one of them is in a critical state, and the resource usage is unbalanced.

[0067] At this point, it is necessary to adjust both GPU memory and system memory simultaneously, reclaiming their storage resources to ensure normal user operation.

[0068] S120: When the unified pressure value is within the fourth set range and both GPU memory and system memory are in a critical state, an emergency degradation scheduling is triggered for GPU memory and system memory.

[0069] The fourth setting range is greater than the third setting range, which is a value range close to the usage limit. At this time, the unified pressure value is close to the maximum value, indicating that the GPU memory and system memory are under great pressure and both are in a critical state, with serious resource imbalance.

[0070] At this point, it is necessary to adjust both GPU memory and system memory simultaneously, urgently downgrading their usage to a lower level to avoid crashes.

[0071] Referring to the table below, in one embodiment, the first set range is less than 0.6, the second set range is 0.6-0.8, the third set range is 0.8-0.9, and the fourth set range is greater than 0.9.

[0072] By setting the above range, the usage status of GPU memory and system memory can be accurately corresponded, making it easy to accurately coordinate and adjust GPU memory and system memory.

[0073] In one embodiment of the present invention, step S117, the operation of migrating inactive GPU textures from GPU memory to system memory, includes the following steps: S1171: Identifies inactive GPU textures in GPU memory.

[0074] The GPU textures in the GPU memory can be statistically analyzed by texture access frequency, and GPU textures that have not been accessed for more than a set time (such as 60 seconds) are identified as inactive GPU textures.

[0075] S1172: Migrate inactive GPU textures from GPU memory to system memory.

[0076] Inactive GPU textures can be migrated using cudaMemcpy or similar functions from the GPU API.

[0077] S1173: Maintain inactive GPU textures in system memory. When an inactive GPU texture is accessed again, delay it for a set time before loading it back into GPU memory.

[0078] To ensure that inactive GPU textures can be used normally, they need to be maintained after being migrated to system memory. When inactive GPU textures are accessed again, they should be delayed for a set time (such as 3s, 5s, etc.) before being loaded back into GPU memory to avoid sudden changes in user experience caused by sudden resource loading.

[0079] In one embodiment of the present invention, step S118, triggering the system memory data compression operation, includes the following steps: S1181: Identifies compressible memory data in system memory.

[0080] For example, log files and cached data in system memory can be identified as compressible memory data.

[0081] S1182: Compresses compressible memory data using a GPU-accelerated compression algorithm.

[0082] For example, compressible data can be compressed using NVIDIA's nvCOMP library.

[0083] S1183: Store the compressed compressible data in system memory.

[0084] This frees up some storage space in the system memory, relieving pressure on the system memory. Once the system memory pressure returns to normal, the compressible data can be decompressed in the system memory for later use, or the compressible data can remain compressed to ensure ample system memory.

[0085] In one embodiment of the present invention, step S119, triggering the cooperative recycling operation, includes the following steps: S1191: Identify inactive GPU textures in GPU memory and migrate them to system memory; S1192: Identifies compressible data in system memory and compresses it using GPU-accelerated algorithms; and S1193: Triggers system memory reclamation to free up system memory space.

[0086] Through the processing of steps S1191 to S1193 above, the operations of migrating inactive GPU textures in GPU memory to system memory, compressing system memory data, and reclaiming system memory are triggered simultaneously, so as to quickly and effectively alleviate the resource imbalance between GPU memory and system memory.

[0087] In one embodiment of the present invention, step S120, triggering an emergency downgrade operation, includes the following steps: S1201: Reduce the video encoding quality of the cloud phone platform to reduce the usage of the video encoding buffer; S1202: Reduces the GPU memory quota to free up GPU memory resources; S1203: Lowers the system memory level to free up system memory resources; and S1204: Triggers aggressive memory reclamation to quickly free up system memory space.

[0088] Through the processing of steps S1201 to S1204 above, the pressure on video encoding buffer, GPU memory and system memory is relieved at the same time, and the overall storage resources and storage space occupied by the cloud phone platform are released quickly and effectively.

[0089] The following is an example of how this invention performs in actual use: Example 1 - GPU memory-system memory co-optimization in cloud gaming scenarios: ① An example of running the game "Genshin Impact" on a cloud gaming platform.

[0090] ② Technical issues: During game operation, the GPU memory usage is 95%, the system memory usage is 60%, and the game frame rate drops from 60FPS to 25FPS, resulting in a poor user experience.

[0091] ③ Applying the technical solution of this invention: when the resource imbalance index imbalance=35 is detected, GPU texture migration is triggered, inactive GPU textures are identified in GPU memory, and 500MB of inactive GPU textures are migrated from GPU memory to system memory.

[0092] ④ Technical effect: GPU memory usage dropped to 75%, game frame rate recovered to 55 FPS, and frame rate increased by 120%.

[0093] In one embodiment of the present invention, the session state is defined in a fine-grained manner as four types, including a first session state, a second session state, a third session state, and a fourth session state. The resource allocation strategy includes a first allocation strategy, a second allocation strategy, a third allocation strategy, and a fourth allocation strategy. Please refer to [link to relevant documentation]. Figure 4 In step S13, the step of detecting the user's current session state and adopting an appropriate resource allocation strategy based on the current session state includes the following steps: S131: If it is detected that the user is online and using the cloud phone platform, the user's current session state is determined to be the first session state, and the first allocation strategy corresponding to the first session state is adopted. The first allocation strategy is: set the system CPU quota to 100%, set the GPU memory quota to 100%, set the system memory quota to the normal level, and set the encoding quality to high quality.

[0094] In the first session state (SESSION_ONLINE_FOREGROUND), the user is online and using the cloud phone platform (a foreground application is detected). At this time, the user requires more resources. The first allocation strategy is adopted to configure the CPU quota, GPU quota, system memory and encoding quality to the highest level to avoid storage resource reclamation and ensure that the user gets the best user experience.

[0095] S132: If a user is detected to be online but the application is running in the background, the user's current session state is determined to be the second session state, and a second allocation strategy corresponding to the second session state is adopted. The second allocation strategy is: set the system CPU quota to the first set value, set the GPU memory quota to the second set value, set the system memory quota to the increased level, and set the encoding quality to medium quality. The first set value is greater than the second set value and less than 1.

[0096] The second session state (SESSION_ONLINE_BACKGROUND) is when the user is online but the application is running in the background. At this time, the user requires relatively few resources. The second allocation strategy is adopted to configure CPU quota, GPU quota, system memory and encoding quality relatively lower to reduce resource usage and occupation, while ensuring the overall quality when the application switches from the background to the foreground.

[0097] S133: If a user is detected to be online but the cloud phone platform is idle, the user's current session state is determined to be the third session state, and the third allocation strategy corresponding to the third session state is adopted. The third allocation strategy is: setting the system CPU quota to the second set value, setting the GPU memory quota to the third set value, setting the system memory quota to aggressive reclamation and setting the encoding quality to low quality. The third set value is less than the second set value.

[0098] The third session state (SESSION_ONLINE_IDLE) is when the user is online but the platform is idle (no interactive operation for more than a certain period of time (e.g., 30s)). At this time, the user needs fewer resources. The third allocation strategy is adopted to configure the CPU quota, GPU quota, system memory and encoding quality at a lower level, further reducing resource occupation and increasing resource recycling, thereby reducing the operating load of the cloud phone platform.

[0099] S134: If a user is detected to be offline, the user's current session state is determined to be the fourth session state, and the fourth allocation strategy corresponding to the fourth session state is adopted. The fourth allocation strategy is: set the system CPU quota to the third set value, set the GPU memory quota to 0, and set the system memory quota to the minimum level and stop encoding.

[0100] The fourth session state (SESSION_OFFLINE) is when the user is offline (connection is detected to be broken). At this time, the user does not need to use resources. The fourth allocation strategy is adopted to configure the CPU quota, GPU quota, system memory and encoding quality to the lowest level, and the CPU keeps running at the lowest power.

[0101] Referring to the table below, in one embodiment, the first setting value is 50%, the second setting value is 50%, the third setting value is 30%, and the fourth setting value is 10%.

[0102] By setting the above values, the user's session state can be accurately matched, which facilitates accurate and coordinated adjustment of CPU quota, GPU quota, system memory and encoding quality.

[0103] The following is an example of how this invention manifests in actual use: Example 2 - Resource release when the user is offline: ① A user logged off after using a cloud phone for work.

[0104] ② Applying the technical solution of this invention: when a user is detected to be offline (e.g., when WebSocket connection is detected to be disconnected), the offline status is confirmed after a 10-second delay, and the resource quota is gradually reduced: CPU quota from 100% to 10%, GPU quota from 100% to 0%, system memory quota from normal level to minimum level (200MB), and video encoding is stopped.

[0105] ③ Technical effect: The container resource usage is reduced from 2GB to 200MB, and the freed-up resources can be allocated to other online users.

[0106] In one embodiment of the present invention, in step 14, the smooth switching mechanism includes a delayed confirmation of the switch for a first set duration, a gradual adjustment of the step size setting range, and a second set duration for reserving GPU memory and / or system memory resources, wherein the second set duration is at least twice the first set duration.

[0107] By employing a three-stage smooth switching mechanism of "delayed confirmation → gradual adjustment step size → resource retention," the abrupt change in user experience caused by the traditional "one-step" resource adjustment is avoided. Real-world testing shows that the smooth switching mechanism reduces lag rate by 80% (from 15% to 3%) and complaint rate by 75% (from 12% to 3%) during peak user periods.

[0108] The first set duration can be 10 seconds, with a set range of 10%, and the second set duration can be 30 seconds.

[0109] Furthermore, resource pre-allocation includes cold start optimization, texture preloading, service preheating, and network pre-connection. Cold start optimization is to pre-incubate the application's startup process in advance. Texture preloading is to load the GPU textures corresponding to the application into the GPU memory in advance. Service preheating is to start the services required by the application in advance. Network pre-connection is to establish the network connection between the application and the server in advance.

[0110] Specifically: Cold start optimization can be achieved by pre-incubating processes through zygote fork; for game applications that are predicted to launch, textures can be pre-loaded into GPU memory; and service warm-up can be achieved by starting the applications that the application depends on in advance. By predicting the applications that users are about to launch, optimizing cold starts in advance, pre-loading textures, warming up services, and pre-establishing network connections, the startup latency of common applications can be reduced to less than 0.5 seconds, improving startup speed by 80% and greatly improving the user experience.

[0111] It should be noted that the user behavior prediction mechanism of this invention differs from the "performance factor trend prediction" of the prior art in the following ways: The prediction object of this invention is user behavior (application startup, switching), rather than service performance factors; the prediction purpose is to pre-allocate resources and reduce startup latency, rather than adjust resource quotas; the prediction basis is the user's historical behavior patterns (time, application, operation sequence), rather than performance changes.

[0112] In addition, existing cloud phone platform scenarios also have the following significant characteristics: (1) Real-time requirements of video encoding stream: The cloud phone encodes the screen into H.264 / H.265 video streams and transmits them in real time. The encoding delay needs to be controlled within 50ms.

[0113] (2) Android-specific memory management mechanisms: including Zygote process hatching mechanism (Copy-on-Write), Ashmem anonymous shared memory, Binder IPC, LMK (Low Memory Killer), etc.

[0114] (3) High-density multi-tenant environment: A single physical machine runs 50-100 Android instances, and resource competition is fierce, so it is necessary to ensure fairness among tenants.

[0115] However, existing cloud phone platform technologies still have the following drawbacks: Defect 1: The "black box" nature of Android's unique memory mechanism makes optimization difficult. Current technologies lack understanding of Android's unique memory management mechanisms: child processes forked by the Zygote process share the parent process's read-only memory pages (COW mechanism). Existing memory statistics double-count this memory, leading to an overestimation of memory pressure by 30-40%, causing excessive garbage collection; the Ashmem anonymous shared memory reference counting mechanism is opaque, prone to memory leaks or excessive garbage collection, which can affect multiple applications simultaneously; Binder IPC memory allocation lacks an early warning mechanism, and insufficient memory can cause system lag, but current technologies cannot provide advance warning. These mechanisms are reasonable in the native Android system, but they expose significant flaws in the high-density multi-tenant environment of cloud phones.

[0116] Defect 2: There is a conflict between memory protection and dynamic adjustment of the video encoding buffer, and there is a lack of dedicated management. The video encoding buffer needs to be protected against reclamation, but its size also needs to be dynamically adjusted according to network conditions. These two requirements are contradictory: locking with `mlock()` can prevent reclamation but reduces memory utilization efficiency; leaving it unlocked may result in reclamation when memory is low. Cloud phones need to encode video streams in real time, and reclamation of the video encoding buffer can lead to a 3-5% frame drop rate, resulting in screen tearing or stuttering. When network conditions change (such as switching from WiFi to 4G), the encoding bitrate and buffer size need to be adjusted. Current technology cannot respond in time, resulting in an average black screen time of 3-5 seconds. In weak network environments, the untimely adjustment of the buffer in the PalmPai cloud phone accounts for 35% of all video quality complaints due to "screen stuttering".

[0117] Defect 3: Resource conflicts in high-density multi-tenant environments Running 50-100 Android instances on a single physical machine, resource contention between containers leads to performance fluctuations, with a performance variance coefficient (standard deviation / mean) as high as 0.42, indicating severe unfairness. Abnormal behavior in one container (such as memory leaks) can affect other containers (the "noisy neighbor" problem). Overall resource utilization is only 68%, with 32% of resources wasted.

[0118] To resolve the above defects, please refer to Figure 5 In one embodiment of the present invention, the collaborative management method further includes the step of: S15: Create independent channels for the graphics buffer and video encoding buffer of the cloud phone platform, and set minimum memory values ​​and memory warning thresholds for the independent channels.

[0119] To ensure the critical performance of graphics rendering and video encoding, this embodiment of the invention creates independent channels (cgroups) for the graphics buffer (SurfaceFlinger) and the video encoding buffer (video_encoder), creates directories such as / sys / fs / cgroup / surfaceflinger / and / sys / fs / cgroup / video_encoder / , sets a minimum memory value (memory.min) to ensure minimum memory requirements, and sets a memory warning threshold (memory.low) as a warning threshold to ensure their basic resource requirements.

[0120] S16: Lock the video encoding buffer using the mlock mechanism.

[0121] The mlock() function locks the video encoding buffer to prevent the video buffer from being swapped, thus ensuring the real-time performance and quality of the video stream.

[0122] S17: Dynamically adjust the buffer configuration of the graphics buffer based on the current session state.

[0123] The graphics buffer configuration is dynamically adjusted based on the user's session state, ensuring that the graphics buffer configuration matches the user's session state, guaranteeing user experience during active sessions, and reducing the platform's buffer usage during inactive sessions.

[0124] S18: Dynamically adjust the buffer configuration of the video encoding buffer based on the current network conditions.

[0125] The encoding quality and buffer size are dynamically adjusted based on network bandwidth, and immediately adjusted when the network changes to adapt to network changes and ensure user experience.

[0126] S19: Targeted optimizations are performed on the Zygote process, Ashmem region, and Binder buffer of the cloud phone platform.

[0127] Targeted optimizations include Zygote shared page identification and deduplication statistics, Ashmem reference count management, and Binder buffer monitoring and early warning.

[0128] S20: Obtain the resource usage and average resource usage of each container on the cloud phone platform, calculate the deviation coefficient of each container, and adjust the resource quota and memory reclamation frequency of the container according to the magnitude of the deviation coefficient. Each container includes the system CPU, GPU memory and system memory.

[0129] The resource usage is container_usage[i], which represents the resource usage of container i (representing the weighted sum of the resource usage of container i in three dimensions: system CPU, system memory, and GPU memory). Average resource usage: avg_usage=(1 / n)×Σcontainer_usage[i], where n is the total number of containers on the cloud phone platform, and average resource usage avg_usage is used to characterize the average resource usage level of all containers; Deviation coefficient: deviation[i]=(container_usage[i]-avg_usage) / avg_usage.

[0130] By obtaining the resource usage (container_usage[i]) and average resource usage (avg_usage) of each container, and calculating the deviation coefficient (deviation[i]), the deviation coefficient is used to monitor the resource usage of each container. When the deviation coefficient of a container changes differently (such as when it is greater than or less than a set threshold), fairness is triggered, and the resource quotas and memory reclamation frequency of the system CPU, GPU memory and system memory are adjusted accordingly to ensure resource balance among them.

[0131] S21: Monitor the resource growth rate of each container and adjust the resource quota of the container according to the size of the resource growth rate.

[0132] For example, when the resource growth rate exceeds a threshold (e.g., memory growth > 500MB within 1 second), it is determined to be abnormal. At this time, the abnormal container can be isolated and its resource quota can be limited to achieve noisy neighbor detection and suppression.

[0133] In one embodiment of the present invention, the session state includes a first session state, a second session state, and a third session state, and step S17 includes the following steps: S171: If the user's current session state is the first session state, then adjust the graphics buffer to a triple-buffered configuration.

[0134] The first session state (SESSION_ONLINE_FOREGROUND) mentioned above is the same as the first session state here, that is, the user is online and using a cloud phone. To ensure the best display effect, the graphics buffer is adjusted to a triple buffer configuration with all three buffers enabled (e.g., 256MB).

[0135] S172: If the user's current session state is the second session state, then adjust the graphics buffer to a double-buffered configuration.

[0136] The second session state (SESSION_ONLINE_BACKGROUND) mentioned above is the same as the second session state here, that is, the user is online but the application is in the background. At this time, reduce the display effect to reduce the system load, adjust the graphics buffer to double buffer configuration, and enable double buffer (e.g., 128MB).

[0137] S173: If the user's current session state is the third session state, then adjust the graphics buffer to a single-buffered configuration.

[0138] The third session state here is a combination of the third session state (SESSION_ONLINE_IDLE) and the fourth session state (SESSION_OFFLINE) mentioned above. That is, the user is online but idle, or the user is offline. At this time, the display effect will be reduced to the minimum, and the graphics buffer will be adjusted to a single buffer configuration. Simply enable single buffering (e.g., 64MB).

[0139] Furthermore, when GPU memory is scarce, inactive textures can be intelligently swapped out using texture heat scoring (inactive textures are defined as textures that have not been accessed for more than 60 seconds and are not foreground application textures), while foreground application textures are retained in GPU memory to alleviate GPU memory pressure.

[0140] In one embodiment of the present invention, network status includes network bandwidth and whether the network has switched, and step S18 includes the following steps: S181: If the current network bandwidth is greater than the first bandwidth value, then increase the encoding quality and buffer size of the video encoding buffer.

[0141] When the current network bandwidth is greater than the first bandwidth value (e.g., 10Mbps), it indicates that the network bandwidth is sufficient. At this time, improve the encoding quality and buffer size to ensure the display effect and improve the user experience.

[0142] S182: If the current network bandwidth is less than the second bandwidth value, reduce the encoding quality and buffer size of the video encoding area.

[0143] When the current network bandwidth is less than the second bandwidth value (e.g., 1Mbps), it indicates that the network bandwidth is tight. At this time, reduce the encoding quality and buffer size, and control the display effect to avoid screen stuttering.

[0144] S183: If the current network switches, adjust the buffer size of the video encoding area.

[0145] When the current network changes (such as switching from WiFi to 4G), immediately adjust the size of the video encoding buffer to avoid a black screen.

[0146] Through the processing of steps S181 to S183 above, actual tests show that the frame loss rate has decreased from 3-5% to below 0.1%, complaints about "screen stuttering" have decreased by 90%, and the black screen time during network switching has decreased from 3-5 seconds to less than 0.5 seconds.

[0147] In one embodiment of the present invention, step S19 includes the following steps: S191: Identify shared memory pages in the Zygote process, perform deduplication statistics on shared memory pages when calculating container resource usage, and mark shared memory pages as non-reclaimable.

[0148] Step S191 involves Zygote shared memory page identification and deduplication statistics: First, shared memory pages are identified through the / proc / [pid] / smaps file (marked as Shared_Clean or Shared_Dirty). Then, when calculating the resource usage of the container, deduplication statistics are performed on Zygote shared memory pages, and Zygote shared memory pages are marked as "unreclaimable" to prevent them from being mistakenly reclaimed by kswapd.

[0149] S192: Count the references for each Ashmem region. When the count is 0, the corresponding Ashmem region is reclaimed. The Ashmem region is marked with priority according to its use. When reclaiming, the Ashmem region with lower priority is reclaimed first.

[0150] Step S192 is for Ashmem region reference count management: First, maintain a reference count ref_count for each Ashmem region. Only when ref_count=0 is the Ashmem region reclaimed. The Ashmem region is marked with priority (0-100) according to its purpose. When reclaiming, the Ashmem region with lower priority is reclaimed first.

[0151] S193: Monitor the usage of the Binder buffer; when the usage rate of the Binder buffer exceeds the first set usage rate, determine that the Binder buffer is under pressure and trigger an alert; when the usage rate of the Binder buffer is greater than the second set usage rate, pre-allocate the Binder buffer; when the pressure on the Binder buffer is greater than the set pressure, rate-limit calls to the non-critical Binder buffer, where the second set usage rate is greater than the first set usage rate.

[0152] Step S193 is Binder buffer monitoring and early warning: The usage of the Binder buffer is monitored through the / proc / binder / stats file; when the usage rate exceeds the first set usage rate (e.g., 80%), it is determined to be Binder pressure and an early warning is triggered; when the usage rate exceeds the second set usage rate (e.g., 90%), the Binder buffer is pre-allocated; when the pressure of the Binder buffer is greater than the set pressure (e.g., the usage rate is greater than 95%), it indicates that the pressure is high, and non-critical Binder buffer calls are rate-limited.

[0153] The following is an example of how this invention performs in actual use: Example 3 - Zygote shared memory page optimization: ① A cloud-based mobile container runs 20 Android applications; ② Technical issue: Memory statistics show that the container used 3GB of memory, triggering garbage collection, but the actual deduplicated memory is only 2GB, resulting in 1GB of duplicate statistics; ③ Applying the technical solution of this invention: Identify Zygote shared memory pages (by using the Shared_Clean flag in / proc / [pid] / smaps), perform deduplication statistics on Zygote shared memory pages, and the actual memory usage is 2GB.

[0154] ④ Technical effects: The problem of overestimating memory pressure has been solved, excessive recycling has been avoided, and application stability has been improved.

[0155] In one embodiment of the present invention, step S20, which involves adjusting the container's resource quota and memory reclamation frequency based on the magnitude of the deviation coefficient, includes the following steps: S201: When the deviation coefficient of a container is greater than the first coefficient threshold, reduce the container's resource quota and increase the memory reclamation frequency.

[0156] When the deviation coefficient of a container is greater than the first coefficient threshold (e.g., deviation>0.3), it indicates that the current container is overused. For overused containers, reduce their resource quota and increase the frequency of memory reclamation.

[0157] S202: When the deviation coefficient of a container is less than the second coefficient threshold, increase the container's resource quota and reduce the memory reclamation frequency.

[0158] When the deviation coefficient of a container is less than the second coefficient threshold (e.g., deviation < -0.3), it indicates that the current container is underutilized. For underutilized containers, increase their resource quota and reduce the frequency of memory reclamation.

[0159] In one embodiment of the present invention, step S21, which involves adjusting the resource quota of the container according to the magnitude of the resource growth rate, includes the following steps: S211: When the resource growth rate is greater than the first growth rate threshold, the corresponding container is judged as abnormal, and the resource quota of the container judged as abnormal is adjusted to the minimum.

[0160] When the resource growth rate of a container exceeds the first growth rate threshold (e.g., 100MB / s), it indicates that the container's resource growth rate is too fast and is an abnormal situation. At this time, the CPU real-time scheduling time is limited by cgroup's cpu.rt_runtime_us, and the memory quota is hard-limited by memory.limit_in_bytes to reduce the resource quota of the abnormal container to a minimum and prevent it from affecting other containers.

[0161] S212: When the resource growth rate exceeds the second growth rate threshold, the corresponding container will be judged as a serious anomaly and the container judged as a serious anomaly will be restarted.

[0162] When the resource growth rate of a container exceeds the second growth rate threshold (e.g., 200MB / s), it indicates that the container's resource growth rate is too fast, which is a serious abnormal situation. At this time, for containers with serious abnormalities (e.g., memory leaks), the container is restarted to prevent the container from being severely damaged and causing a significant impact on other containers.

[0163] To verify the effectiveness of the embodiments of the present invention, a 3-month A / B comparison test was conducted in the Zhangpai cloud phone production environment (October-December 2024), covering 100 physical servers, 10,000 Android cloud phone instances, and 100+ application types. The test group adopted the technical solution of the present invention, while the control group adopted the traditional separate management solution. Actual test data shows: 1. GPU memory utilization increased from 67% to 87% (a 30% improvement), and the frame rate was stable at 55 FPS when running Genshin Impact (compared to 25 FPS in the control group). 2. System memory utilization increased from 59% to 78%; 3. The resource imbalance index decreased from 42 to 12 (a reduction of 71%). 4. The lag rate during peak user activity periods decreased from 15% to 3% (an 80% reduction), and the complaint rate decreased from 12% to 3% (a 75% reduction). 5. Application startup delay reduced from 2-3 seconds to less than 0.5 seconds (an 80% improvement); 6. Zygote's shared page deduplication reduces excessive garbage collection by 40%; 7. Ashmem reference counting management reduced the crash rate from 8% to 3.2% (a 60% reduction); 8. Binder memory warnings reduce system lag by 50%; 9. Frame loss rate reduced from 3-5% to below 0.1% (a reduction of 97%+); 10. The black screen time during network switching has been reduced from 3-5 seconds to less than 0.5 seconds; 11. The performance difference coefficient decreased from 0.42 to 0.15 (a 64% reduction in unfairness); 12. Overall resource utilization increased from 68% to 85%, and the number of containers that can run on a single machine increased by 25% (from 80 to 100).

[0164] Based on 100 servers, a 25% increase in resource utilization is equivalent to saving the cost of 25 servers, amounting to 1.25 million yuan. The complaint rate decreases by 75%, reducing customer service costs by 600,000 yuan per year. The ROI reaches 325%, and the investment payback period is approximately 4 months, demonstrating excellent economic benefits.

[0165] Compared with existing technologies, the collaborative management method of GPU memory and system memory in the cloud mobile phone platform of this invention has the following advantages: Advantage 1: GPU memory and system memory coordinated scheduling improves resource utilization. Existing technologies manage GPU memory and system memory separately, leading to uneven resource utilization. This invention achieves coordinated optimization of both through a unified resource view and a collaborative scheduling mechanism. GPU memory utilization is improved by 30%, and game frame rate is improved by 120% (from 25 FPS to 55 FPS). The resource imbalance index is reduced from 42 to 12, resulting in more balanced resource utilization.

[0166] Advantage 2: Conversation awareness enhances user experience Existing technologies cannot detect user session status and may reclaim resources when users are active, leading to a degraded user experience. This invention uses a session-aware mechanism to conserve resources when users are active and actively release resources when users are offline. During periods of high user activity, the lag rate is reduced by 80% (from 15% to 3%), and the user complaint rate is reduced by 75% (from 12% to 3%). Simultaneously, the resource release rate is increased by 60% during offline periods, resulting in an overall 25% improvement in resource utilization.

[0167] Advantage 3: Android mechanism optimization improves stability Existing technologies lack understanding of Android's unique memory management mechanisms, leading to issues such as duplicate counting of Zygote shared pages and improper garbage collection of Ashmem. This invention specifically optimizes mechanisms such as Zygote, Ashmem, and Binder. Deduplication of Zygote shared pages resolves the issue of overestimating memory pressure, reducing excessive garbage collection by 40%. The Ashmem reference counting mechanism reduces application crash rates by 60%. The Binder warning mechanism reduces system lag by 50%.

[0168] Advantage 4: Encoding buffer management ensures video quality Existing technologies lack dedicated management of graphics and video encoding buffers, leading to buffer reclamation and a frame loss rate of 3-5%. This invention, through independent channel management and protection mechanisms, reduces the frame loss rate to below 0.1%, resulting in a 90% decrease in user complaints about "screen stuttering." The black screen time during network switching is reduced from 3-5 seconds to less than 0.5 seconds.

[0169] Advantage 5: Fairness guarantee enhances multi-tenant experience Existing technologies lack fairness guarantees in high-density multi-tenant environments, resulting in a performance difference coefficient between containers as high as 0.42. This invention reduces the performance difference coefficient to 0.15 through fairness guarantee mechanisms and noisy neighbor suppression, reducing unfairness by 64%. Overall resource utilization increases from 68% to 85%, and the number of containers that can run on a single machine increases by 25% (from 80 to 100).

[0170] Advantage 6: Resource pre-allocation reduces application startup latency Existing technologies cannot predict user behavior, and application startup requires waiting for resource allocation, resulting in an average startup delay of 2-3 seconds. This invention, through user behavior prediction and resource pre-allocation, reduces the startup delay of common applications to less than 0.5 seconds, improving startup speed by 80%. User satisfaction ratings have increased from 3.2 / 5.0 to 4.6 / 5.0.

[0171] Please see Figure 6 The collaborative management system 100 for GPU memory and system memory of the cloud mobile phone platform according to an embodiment of the present invention includes: The calculation module 10 is used to obtain the GPU memory parameters of the GPU memory and the system memory parameters of the system memory of the cloud mobile phone platform in real time, and calculate the resource imbalance index and the unified pressure value based on the GPU memory parameters and the system memory parameters. The resource imbalance index is used to characterize the difference in the utilization rate of GPU memory and system memory, and the unified pressure value is used to characterize the pressure status of GPU memory and system memory. The scheduling module 20 is used to construct a unified resource view based on GPU memory parameters, system memory parameters, unified pressure value and resource imbalance index, and make corresponding collaborative scheduling decisions on GPU memory and / or system memory based on the unified resource view. The collaborative scheduling decisions are used to at least adjust the size of GPU memory and / or system memory. The allocation module 30 is used to detect the user's current session state and adopt the corresponding resource allocation strategy according to the current session state. When the user's session state changes, the resource allocation of GPU memory and system memory is adjusted through the resource smooth switching mechanism. Different session states correspond to different resource allocation strategies. The resource allocation strategy is used to adjust at least one of the system CPU quota, GPU memory quota, system memory quota and encoding quality. The resource smooth switching mechanism is used to smoothly switch GPU memory and system memory. The processing module 40 is used to predict the application that the user is about to launch based on the user's historical behavior, and to perform resource pre-allocation processing on the application to be launched. The resource pre-allocation processing is used to reduce application startup delay.

[0172] The collaborative management system 100 for GPU memory and system memory of the cloud mobile phone platform in this embodiment of the invention has the following beneficial effects: ① Compared to existing technologies that manage GPU memory and system memory separately, resulting in uneven resource utilization and other drawbacks, this invention calculates a resource imbalance index and a unified pressure value using GPU memory parameters and system memory parameters. This index characterizes the difference in usage and pressure between GPU memory and system memory, accurately identifying resource imbalance and pressure changes. Furthermore, a unified resource view is constructed based on GPU memory parameters, system memory parameters, unified pressure value, and resource imbalance index. Based on this unified resource view, coordinated scheduling and optimization of GPU memory and system memory are achieved, effectively improving resource utilization and making resource utilization more balanced.

[0173] ② Compared to existing technologies that cannot perceive the user's session state, leading to a decline in user experience due to potential resource reclamation during active user activity, this invention employs a session-aware mechanism to adopt differentiated resource allocation strategies for different session states. This matches resource allocation with the user's actual usage, effectively improving the user experience. Furthermore, when the user's session state changes, a smooth resource switching mechanism adjusts the resource allocation of GPU memory and system memory, seamlessly switching between them and avoiding the abrupt changes in user experience caused by traditional "one-step" resource adjustments.

[0174] In addition, by predicting the applications that users are about to launch based on their historical behavior and pre-allocating resources for those applications, the startup latency of the applications is effectively reduced, and the user experience is significantly improved.

[0175] Please combine Figure 7 As shown in the table below, from a system perspective, the collaborative management system 100 of this invention adopts a four-layer intelligent management architecture, with each layer including corresponding functional modules: The connections and working principles between the above-mentioned layers are as follows: The first layer (User Session Awareness and Behavior Prediction Layer) is responsible for sensing the user session state, predicting user behavior, and passing the user session information to the second layer. The second layer (GPU Memory-System Memory Co-scheduling Layer) is the core layer. Based on the user session information and the unified GPU-memory resource view, it makes co-scheduling decisions and sends resource control instructions to the third layer. The third layer (Android Containerization Adaptation Layer) performs resource control for Android-specific mechanisms and implements specific control through the underlying interface of the fourth layer. The fourth layer (Basic Resource Control Layer) provides specific control interfaces for GPU memory, system memory, and encoder.

[0176] In the description of this specification, references to terms such as "in one embodiment," "in another embodiment," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0177] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for the collaborative management of GPU memory and system memory in a cloud phone platform, characterized in that, include: The system acquires the GPU memory parameters and system memory parameters of the cloud phone platform in real time, and calculates the resource imbalance index and unified pressure value based on the GPU memory parameters and system memory parameters. The resource imbalance index is used to characterize the difference in the utilization rate of the GPU memory and the system memory, and the unified pressure value is used to characterize the pressure status of the GPU memory and the system memory. A unified resource view is constructed based on the GPU memory parameters, the system memory parameters, the unified stress value, and the resource imbalance index. Based on the unified resource view, corresponding collaborative scheduling decisions are made on the GPU memory and / or the system memory. The collaborative scheduling decisions are used to at least adjust the size of the GPU memory and / or the system memory. The system detects the user's current session state and adopts a corresponding resource allocation strategy based on this state. When the user's session state changes, a resource smoothing mechanism adjusts the resource allocation between the GPU memory and system memory. Different session states correspond to different resource allocation strategies. These strategies adjust at least one of the following: system CPU quota, GPU memory quota, system memory quota, and encoding quality. The resource smoothing mechanism smoothly switches between the GPU memory and system memory. Based on the user's historical behavior, the system predicts the applications the user is about to launch and performs resource pre-allocation for those applications to reduce application startup delays.

2. The method for collaborative management of GPU memory and system memory in a cloud phone platform according to claim 1, characterized in that, The collaborative management method also includes: Create independent channels for the graphics buffer and video encoding buffer of the cloud phone platform, and set minimum memory values ​​and memory warning thresholds for the independent channels; The video encoding buffer is locked using the mlock mechanism; The buffer configuration of the graphics buffer is dynamically adjusted based on the current session state; The buffer configuration of the video encoding buffer is dynamically adjusted according to the current network conditions; Targeted optimizations were performed on the Zygote process, Ashmem region, and Binder buffer of the cloud phone platform. The resource usage and average resource usage of each container on the cloud phone platform are obtained, and the deviation coefficient of each container is calculated. Based on the magnitude of the deviation coefficient, the resource quota and memory reclamation frequency of the containers are adjusted. Each container includes the system CPU, the GPU memory, and the system memory. Monitor the resource growth rate of each container and adjust the resource quota of the container according to the magnitude of the resource growth rate.

3. The method for collaborative management of GPU memory and system memory in a cloud phone platform according to claim 1, characterized in that, The GPU memory parameters include total GPU memory, GPU memory usage, and GPU memory utilization rate. The system memory parameters include total system memory, system memory usage, and system memory utilization rate. The calculation of the resource imbalance index and unified pressure value based on the GPU memory parameters and the system memory parameters includes: The GPU memory utilization rate is calculated based on the total amount of GPU memory and the amount of GPU memory used. Obtain the first set parameter, and calculate the resource imbalance index based on the GPU memory usage rate, the system memory usage rate and the first set parameter; The system memory utilization rate is calculated based on the total system memory and the system memory usage; and Obtain the GPU weight coefficient, memory weight coefficient, and a second set parameter; calculate a unified pressure value based on the GPU memory usage rate, the GPU weight coefficient, the system memory usage rate, the memory weight coefficient, the resource imbalance index, and the second set parameter. Wherein, the first setting parameter is half of the second setting parameter, and the sum of the GPU weight coefficient and the memory weight coefficient is equal to 1.

4. The method for collaborative management of GPU memory and system memory in a cloud phone platform according to claim 1, characterized in that, The collaborative scheduling decisions include not triggering scheduling, triggering scheduling to migrate inactive GPU textures from the GPU memory to the system memory, triggering scheduling to compress compressible data in the system memory, triggering collaborative reclamation scheduling, and triggering emergency degradation scheduling. The step of making corresponding collaborative scheduling decisions for the GPU memory and / or the system memory based on the unified resource view includes: Determine the magnitude of the unified pressure value, the status of the GPU memory, the status of the system memory, and the magnitude of the resource imbalance index in the unified resource view; When the unified pressure value is within the first set range, the GPU memory is in a normal state, and the system memory is in a normal state, scheduling is not triggered for the GPU memory and the system memory. When the unified pressure value is within the second set range, the GPU memory is under pressure, the system memory is sufficient, and the resource imbalance index is less than the resource threshold, the inactive GPU textures in the GPU memory are migrated to the system memory for scheduling. When the unified pressure value is within the second set range, the GPU memory is in a sufficient state, the system memory is in a tense state, and the resource imbalance index is less than the resource threshold, the compressible data in the system memory is compressed and scheduled. When the unified pressure value is within a third preset range, and the GPU memory or the system memory is in a critical state, a coordinated reclamation scheduling is triggered for the GPU memory and the system memory; and When the unified pressure value is within the fourth set range and both the GPU memory and the system memory are in a critical state, an emergency degradation scheduling is triggered for the GPU memory and the system memory.

5. The method for collaborative management of GPU memory and system memory in a cloud phone platform according to claim 4, characterized in that, The step of migrating inactive GPU textures from the GPU memory to the system memory includes: Identify inactive GPU textures in the GPU memory; Migrate inactive GPU textures from the GPU memory to the system memory; and The inactive GPU texture is maintained in the system memory. When the inactive GPU texture is accessed again, it is delayed for a set time before being loaded back into the GPU memory. The triggering of system memory data compression includes: Identify compressible memory data in system memory; The compressible memory data is compressed using a GPU-accelerated compression algorithm; and The compressed compressible data is stored in system memory; The triggering of collaborative recycling includes: Identify inactive GPU textures in the GPU memory and migrate the inactive GPU textures to the system memory; Identify compressible data in the system memory and compress the compressible data using a GPU-accelerated algorithm; and Trigger system memory reclamation; The triggering of emergency downgrade includes: Reduce the video encoding quality of the cloud phone platform; Reduce the GPU memory allocation; Lower the system memory level; and Trigger aggressive memory reclamation.

6. The method for collaborative management of GPU memory and system memory in a cloud phone platform according to claim 1, characterized in that, The session states include a first session state, a second session state, a third session state, and a fourth session state. The resource allocation strategies include a first allocation strategy, a second allocation strategy, a third allocation strategy, and a fourth allocation strategy. Detecting the user's current session state and adopting a corresponding resource allocation strategy based on the current session state includes: If a user is detected to be online and using a cloud phone platform, the user's current session state is determined to be the first session state, and a first allocation strategy corresponding to the first session state is adopted. The first allocation strategy is: setting the system CPU quota to 100%, the GPU memory quota to 100%, the system memory quota to normal level, and the encoding quality to high quality. If a user is detected to be online but the application is running in the background, the user's current session state is determined to be the second session state, and a second allocation strategy corresponding to the second session state is adopted. The second allocation strategy is: setting the system CPU quota to a first set value, setting the GPU memory quota to a second set value, setting the system memory quota to an increased level, and setting the encoding quality to medium quality. The first set value is greater than the second set value and less than 1. If a user is detected to be online but the cloud phone platform is idle, the user's current session state is determined to be a third session state, and a third allocation strategy corresponding to the third session state is adopted. The third allocation strategy is as follows: setting the system CPU quota to a second preset value, setting the GPU memory quota to a third preset value, setting the system memory quota to aggressive reclamation, and setting the encoding quality to low quality, wherein the third preset value is less than the second preset value; and If a user is detected to be offline, the user's current session state is determined to be the fourth session state, and a fourth allocation strategy corresponding to the fourth session state is adopted. The fourth allocation strategy is: setting the system CPU quota to the third set value, setting the GPU memory quota to 0, and setting the system memory quota to the minimum level and stopping encoding.

7. The method for collaborative management of GPU memory and system memory in a cloud phone platform according to claim 1, characterized in that, The smooth switching mechanism includes a first set duration for delayed confirmation of switching, a step size setting range for gradual adjustment, and a second set duration for reserving the GPU memory and / or the system memory resources, wherein the second set duration is at least twice the first set duration. The resource pre-allocation includes cold start optimization, texture preloading, service preheating, and network pre-connection. The cold start optimization is to pre-incubate the application's startup process in advance. The texture preloading is to load the GPU texture corresponding to the application into the GPU memory in advance. The service preheating is to start the services required by the application in advance. The network pre-connection is to establish a network connection between the application and the server in advance.

8. The method for collaborative management of GPU memory and system memory in a cloud phone platform according to claim 2, characterized in that, The session states include a first session state, a second session state, and a third session state. The step of dynamically adjusting the buffer configuration of the graphics buffer based on the current session state includes: If the user's current session state is the first session state, the graphics buffer is adjusted to a triple buffer configuration; if the user's current session state is the second session state, the graphics buffer is adjusted to a double buffer configuration; if the user's current session state is the third session state, the graphics buffer is adjusted to a single buffer configuration. The network conditions include network bandwidth and whether the network is switching. The step of dynamically adjusting the buffer configuration of the video encoding buffer based on the current network conditions includes: If the current network bandwidth is greater than the first bandwidth value, the encoding quality and buffer size of the video encoding buffer are increased; if the current network bandwidth is less than the second bandwidth value, the encoding quality and buffer size of the video encoding buffer are decreased; if the current network switches, the buffer size of the video encoding buffer is adjusted. The specific optimizations performed on the Zygote process, Ashmem region, and Binder buffer of the cloud phone platform include: Identify shared memory pages in the Zygote process, and when calculating the resource usage of the container, perform deduplication statistics on the shared memory pages and mark the shared memory pages as non-reclaimable; Each Ashmem region is referenced and counted. When the count is 0, the corresponding Ashmem region is reclaimed. The Ashmem region is prioritized according to its usage. When reclaiming, the Ashmem region with lower priority is reclaimed first. The usage of the Binder buffer is monitored. When the usage rate of the Binder buffer exceeds a first set usage rate, it is determined that the Binder buffer is under pressure and an early warning is triggered. When the usage rate of the Binder buffer is greater than a second set usage rate, the Binder buffer is pre-allocated. When the pressure on the Binder buffer is greater than a set pressure, non-critical calls to the Binder buffer are rate-limited. The second set usage rate is greater than the first set usage rate.

9. The method for collaborative management of GPU memory and system memory in a cloud phone platform according to claim 2, characterized in that, The step of adjusting the container's resource quota and memory reclamation frequency based on the magnitude of the deviation coefficient includes: When the deviation coefficient of the container is greater than the first coefficient threshold, the resource quota of the container is reduced and the memory reclamation frequency is increased; When the deviation coefficient of the container is less than the second coefficient threshold, the resource quota of the container is increased and the memory reclamation frequency is reduced; The step of adjusting the resource quota of the container according to the resource growth rate includes: When the resource growth rate is greater than the first growth rate threshold, the corresponding container is determined to be abnormal, and the resource quota of the container determined to be abnormal is adjusted to the minimum. When the resource growth rate exceeds the second growth rate threshold, the corresponding container is determined to be severely abnormal, and the container determined to be severely abnormal is restarted.

10. A collaborative management system for GPU memory and system memory of a cloud phone platform, characterized in that, include: The calculation module is used to obtain the GPU memory parameters of the GPU memory and the system memory parameters of the system memory of the cloud phone platform in real time, and calculate the resource imbalance index and the unified pressure value based on the GPU memory parameters and the system memory parameters. The resource imbalance index is used to characterize the difference in the utilization rate of the GPU memory and the system memory, and the unified pressure value is used to characterize the pressure status of the GPU memory and the system memory. The scheduling module is used to construct a unified resource view based on the GPU memory parameters, the system memory parameters, the unified pressure value and the resource imbalance index, and to make corresponding collaborative scheduling decisions on the GPU memory and / or the system memory based on the unified resource view. The collaborative scheduling decisions are used to at least adjust the size of the GPU memory and / or the system memory. The allocation module is used to detect the user's current session state and adopt a corresponding resource allocation strategy based on the current session state. When the user's session state changes, a resource smoothing switching mechanism is used to adjust the resource allocation of the GPU memory and the system memory. Different session states correspond to different resource allocation strategies. The resource allocation strategy is used to adjust at least one of the system CPU quota, GPU memory quota, system memory quota, and encoding quality. The resource smoothing switching mechanism is used to smoothly switch the GPU memory and system memory. The processing module is used to predict the application that the user is about to launch based on the user's historical behavior, and to perform resource pre-allocation processing on the application to be launched. The resource pre-allocation processing is used to reduce application startup delay.

Images