A system resource allocation method and system based on partition scheduling

Abstract

The application belongs to the technical field of system resource monitoring in the running process of intelligent middle screen terminal, and specifically discloses a system resource allocation method and system based on partition scheduling, wherein the method comprises the following steps: collecting running tasks and bottom layer resource control capabilities, generating task resource records, resource control entities and a resource control capability table; constructing a session dependency graph and a session dependency set according to running time dependency evidence, and generating a scheduling snapshot in combination with resource measurement records; and the technical problem solved by the application is how to determine a resource control domain consistent with an actual control range in the intelligent middle screen terminal according to a current session dependency relationship and effective resource measurement, complete resource granting through cross-period reservation, execution stage version checking and double-sided resource checking, and implement traceable control state recovery under the constraints of receiver demand and resource protection boundaries.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of system resource monitoring in the running process of smart middle screen terminal, and particularly relates to a system resource allocation method and system based on partition scheduling. BACKGROUND

[0002] The smart middle screen terminal can simultaneously run video playing, video calling, voice interaction, device control, system interface, log uploading and content pre-fetching and other services. The central processor, memory and network interface are commonly used by different services. When setting the resource upper limit according to the application name or static process group, the resource allocation object may not be consistent with the actual control range of the underlying interface, and the same control action may affect multiple service members. The inter-process call, shared object usage and audio / video link formed during service running have session attributes, and it is difficult to determine the support range required by the current service only according to static configuration. The resource state comes from different measurement interfaces, and the control upper limit, actual usage and system available amount have different meanings. When the sampling time and statistical window are inconsistent, a resource gap that does not correspond to the same running state may be formed. When multiple scheduling requests are concurrent or cross-periodic, the dependency relationship, object members and control capabilities may change. Reservations made according to a single period cannot cover the control process that has not yet ended, and the supply amount and the gap of the receiving side may also be reused. In addition, the success returned by the control interface does not mean that the requested resource amount has formed a system available amount, and recording the changes of the supply side alone is not enough to handle the amount of the receiving side that has already taken effect. When the resources are recovered, if only the supply side budget is increased without handling the temporary amount of the receiving side, or without checking the business requirements after recovery, resource shortage may occur again. Therefore, a corresponding relationship needs to be established between the resource object, the measurement aperture and the execution state, and complete state basis needs to be provided for resource granting, failure handling and subsequent recovery. SUMMARY

[0003] The technical problem solved by the present application is: how to determine a resource control domain consistent with the actual control range in the smart middle screen terminal according to the current session dependency relationship and effective resource measurement, complete resource granting through cross-period reservation, execution phase version checking and bilateral resource verification, and implement traceable control state recovery under the constraints of receiving side demand and resource protection boundary.

[0004] To solve the above technical problems, the technical solution adopted by the present application is: A system resource allocation method based on partitioned scheduling, applied to a smart mid-screen terminal, includes: collecting running tasks and underlying resource control capabilities, generating task resource records, resource control entities, and resource control capability tables; constructing session dependency graphs and session dependency sets based on runtime dependency evidence, and generating scheduling snapshots in conjunction with resource measurement records; determining the unique resource control domain affiliation of resource control entities based on the session dependency set and scheduling snapshots, determining resource boundaries and resource gaps respectively, and generating resource control domain records and version verification records; filtering supply resource control entities based on the resource control domain records, establishing effective resource reservation records and resource reclamation transactions across scheduling cycles; persisting resource recovery records and verifying versions before execution, determining the verified resource release amount based on measurement results from the resource control entity side and the system side, and granting and updating resource recovery records within the current remaining resource gaps; verifying the running status of active services, basic support services, and supply resource control entities based on the resource recovery records and running measurement records; performing recovery processing and generating scheduling restriction records when verification fails; and restoring and verifying batches of resources when verification is successful and recovery conditions are met, using qualified resource measurement records to update the business resource demand statistics table.

[0005] In one aspect of the present invention, the generation of the task resource record, resource control entity, and resource control capability table includes: Collect the processes, threads, central processing unit control group, memory control group, graphics rendering context, audio session, network socket and device control session corresponding to the running task, and record the resource object instance identifier, parent-child relationship, current session identifier, service type, resource type and resource usage; Based on resource type, resource objects that are jointly controlled by the same control interface instance and control target and cannot have their control quantities set separately are formed into resource control entities. For the same resource type, a non-overlapping range of resource objects is used for measurement, and the parent control restrictions are checked. Based on the existence of the interface, access permissions, allowed parameter range, control granularity, status readback results, and action recovery verification results during the maintenance phase, the states of being precisely executable, degradeable, or non-executable are recorded according to the resource control entity, resource type, and resource control action. Resource control entities in the non-executable state still participate in dependency analysis, resource metering, and resource control domain attribution, but do not execute the corresponding resource control action.

[0006] In one aspect of the present invention, the generation of the session dependency graph and the session dependency set includes: Based on the business focus and task instance records, determine the front-end business root resource control entity. Using the resource control entity as a node, establish directed edges from the dependent party to the dependent party based on inter-process calls, socket communication, shared object usage, graphics buffer transmission and audio link occupancy records, and record the evidence type, validity period and collection status. The first confirmed directed edge is marked as pending confirmation; if it exists for two consecutive valid collection cycles, it is marked as confirmed; if no dependency is found for three consecutive valid collection cycles, it is marked as invalid. The number of times the collection failed is not accumulated, and a temporary protection range is generated along the relationship between pending confirmation and confirmed. From the front-end business root resource control entity, access the dependent entities layer by layer along the confirmed directed edges, and form a session dependency set by deduplicating the accessed list; if there are still unprocessed valid outgoing edges after reaching the upper limit of traversal depth, or if the analysis of the temporary protection scope is not completed, do not generate a new resource reclamation transaction based on the corresponding session.

[0007] In one aspect of the invention, determining the ownership of the unique resource control domain includes: The resource control entities corresponding to the basic support service list are assigned to the basic support resource control domain, the front-end business root resource control entities are assigned to the activity business resource control domain, the remaining resource control entities in the session dependency set are assigned to the session support resource control domain, and the remaining resource control entities are assigned to the reclaimable resource control domain and their reclaim eligibility is recorded. When the same resource control entity meets multiple attribution conditions, a unique attribution is determined according to the order of basic guarantee resource control domain, active business resource control domain, session support resource control domain, and reclaimable resource control domain; the business protection level of each business is determined according to local resource protection rules, where basic guarantee services are level 4, real-time audio and video are level 3, other front-end interactions are level 2, and back-end deferred tasks are level 1; when the same actual control scope involves different protection requirements, the business protection levels of each business within that actual control scope are compared, and resource control actions are restricted according to the protection requirements corresponding to the business protection level with the highest value. For resource control entities referenced by multiple sessions, the total resource quantity is measured once per entity. Incremental requirements that can be attributed are saved separately according to the operation records with session identifiers. The portion that cannot be distinguished by session is retained in the entity's unique attributed resource control domain. Each referencing session is not counted repeatedly in the total resource quantity of that entity.

[0008] In one aspect of the invention, the generation of the scheduling snapshot, resource boundary, and resource gap includes: Resource status is collected according to a unified monotonic clock. The start and end times of the statistical window for measuring and recording the CPU and network are recorded. The actual generation time of memory, temperature and power measurements is recorded. The validity period of session dependencies and resource control capabilities is checked to see if it covers the snapshot reference time. The records required for this resource reclamation transaction are checked for time deviation, data integrity, and version before and after collection. If any check fails, the scheduling snapshot is marked as invalid and is not used to generate a new resource reclamation transaction. Record the current control budget, actual resource usage, available system resources, hard reserve boundary, and flexible operation boundary respectively. Determine the predicted demand based on the business resource demand statistics table and the current business status, calculate the resource gap, and use the graphical continuity, temperature margin, and power margin for resource control action access and operation status verification.

[0009] In one aspect of the invention, the generation and use of the version verification record includes: Save the current session identifier, resource object instance information, session dependency graph version, resource control domain record version, resource control capability table version, local resource protection rule version, and resource control entity member information to form a version verification record that retains the original fields; The system obtains exclusive execution rights for the corresponding control scope through the unified resource management service, compares the version verification record of the original field with the current status item by item, and checks the duration of the scheduling snapshot, the dependency protection status and the current control value. If any check fails, the action that has not yet been executed is stopped. Save the control changes that have been executed in this transaction in the order of actions. In subsequent execution phases, a new version verification record will be formed based on the current state. When an external state change occurs, cancel the actions that have not yet been executed and process the actions that have already produced control effects based on the resource recovery record.

[0010] In one aspect of the invention, the supply resource control entity screening, resource reservation, and resource recycling transaction generation include: Exclude session-dependent objects, temporary protected objects, objects with valid scheduling limit records, and objects with unrecovered control states from the recyclable resource control domain that are eligible for recycling. Determine the supply ceiling based on the portion of the current control budget that exceeds the elastic operating boundary and has not yet been reserved. Within the scope of exclusive processing, the supply limit, the resource gap not yet covered by the receiver, and the existing valid reservation are checked simultaneously. The exclusive scope of the valid reservation is determined by the activation identifier, the resource control entity instance identifier, and the resource type. Resource reservation records are established by comparison and exchange. The reservation amount does not exceed the supply limit, the resource gap not yet covered by the receiver, and the single action limit. Based on the control granularity supported by the interface, generate resource control actions such as reducing the CPU time quota, reducing the managed background cache capacity limit and releasing rebuildable caches, or reducing the local controlled exit transmission budget. If there is no executable level that does not exceed the reserved amount, skip the corresponding object. After the resource control action times out, first confirm the actual execution status, and do not directly release the reserved amount that has already produced control effects.

[0011] In one aspect of the present invention, when determining the verified resource release amount, measurement records with the same statistical caliber are obtained on the resource control entity side and the system side before and after the action of the same transaction. After checking for integrity, time and measurement deviation, the minimum value among the actual reduction in occupation on the entity side, the increase in available capacity on the system side and the reserved capacity is taken, and aligned downward according to the granularity of the receiving interface to determine the verified resource release amount.

[0012] When granting and updating the resource recovery record, the pre-control state, target state, object instance, action generation, and reverse action of each party are saved before the action of the supplier and the receiver are executed. Within the current remaining resource gap, the receiver's quota is increased and read back. The quota increase amount that has taken effect and been confirmed by the read back is recorded as the actual grant amount. The resource recovery record is updated according to the actual grant amount. Executed actions that have not generated actual grants still retain the resource recovery record.

[0013] If the verification fails and the recovery process is executed, the actions already performed are processed according to the resource recovery record.

[0014] When verification is successful and the recovery waiting conditions are met, resource requirements and protection boundaries after the withdrawal of temporary quotas are checked batch by batch. Trial recovery is implemented by first withdrawing the corresponding recipient's temporary quota and then restoring the supplier's control settings, verifying resource gaps and the operational status of all parties. If the trial recovery fails, it is cancelled, and only resource measurement records that have passed verification, have not experienced rollback, and are not subject to resource limitations are used to update the business resource requirement statistics table. In another aspect of the invention, a system resource allocation system based on partitioned scheduling is also disclosed, installed in a smart mid-screen terminal, including a memory and a processor. The memory stores computer programs, as well as task resource records, resource control capability tables, session dependency graphs, session dependency sets, scheduling snapshots, resource control domain records, version verification records, resource reservation records, resource recovery records, and business resource requirement statistics tables. When the processor executes the computer program, it implements the above-described system resource allocation method based on partition scheduling.

[0015] In one aspect of the invention, the memory stores local resource protection rules with versions, the local resource protection rules including a basic protection service list, resource protection boundaries, prohibited recycling objects, allowed actions, single action limits, temperature protection conditions, and power protection conditions; The processor is configured to verify the business policy payload and verification metadata of the remote resource policy, and to limit the verified business types, protection levels, allowed downgrade ranges and effective time windows to the range allowed by the local resource protection rules, and to reject content that expands the underlying resource control capabilities or reduces the protection requirements of basic security services. The processor is also configured to stop new transactions and process the recovery of existing control states before planned upgrades or interface replacements, scan unrecovered resource recovery records after abnormal restarts or unplanned interface changes, verify object instances, current control states and available recovery interfaces, retain the pending maintenance state when the recovery path cannot be confirmed, and not perform old recovery actions on new objects that reuse the same number.

[0016] Compared with the prior art, the present invention has the following beneficial effects: This invention forms resource control entities based on actual control interfaces and control objectives, ensuring that resource measurement, control, and recovery correspond to specific operating system objects. It forms session dependency sets based on session calls and object persistence records, and retains temporary protection scopes for relationships awaiting confirmation, helping to reduce erroneous reclamation of current business support objects. By distinguishing control budgets, actual occupancy, and system availability, and verifying measurement windows and record versions, resource gaps and control bases have clear sources. Supplier quotas and receiver gaps are reserved within the same exclusive processing scope, remaining valid throughout the transaction's cross-cycle execution, helping to reduce duplicate reservations and grants. Before resource control, the states of both parties are saved; after control, the grant amount is limited through entity-side and system-side measurements, preserving recovery basis for zero grants, partial execution, and results awaiting confirmation. Resource recovery simultaneously checks the receiver's demand after withdrawing temporary quotas, the supplier's budget, and system protection boundaries, and processes post-recovery business changes through batch verification. Verified resource records that are not subject to resource limitations are used to update subsequent demand statistics, ensuring that demand determination corresponds to the verified operational records. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 This is a flowchart of a system resource allocation method based on partition scheduling according to the present invention.

[0019] Figure 2 This is a flowchart of a sub-step in step 1 of a system resource allocation method based on partition scheduling according to the present invention.

[0020] Figure 3 This is a flowchart of a sub-step in step 2 of a system resource allocation method based on partition scheduling according to the present invention.

[0021] Figure 4This is a flowchart of a sub-step in step 3 of a system resource allocation method based on partition scheduling according to the present invention.

[0022] Figure 5 This is a flowchart of step 4 in a system resource allocation method based on partition scheduling according to the present invention. Detailed Implementation

[0023] The present invention will be further described below with reference to embodiments. These embodiments are merely some, not all, of the embodiments of the present invention. The following embodiments illustrate the data source, processing order, judgment conditions, execution interface, exception handling, and recovery process of this application. The scope of protection is defined by the claims.

[0024] The smart mid-screen terminal in this embodiment has a processor, memory, display components, audio components, network interface, and device control interface. The terminal firmware includes a unified resource management service. This service has permissions to read the status of managed resources, access corresponding control interfaces, receive service focus notifications, and save transaction records. The operating system version used by the terminal does not directly determine the existence of corresponding control capabilities; specific capabilities are determined based on the actual kernel configuration, interfaces, permissions, and maintenance test results.

[0025] This implementation uses a quad-core CPU, 2 GiB of physical memory, and 32GB of embedded storage as the set implementation environment. The operating system can be Android 9 with the corresponding firmware interface. The above configuration is for illustrating the measurement range and does not constitute a conclusion that testing of a particular product has been completed. The CPU online cores, accessible memory, network egress, and control interface are read after startup. If the actual read results are inconsistent with the configuration, the actual capability record shall prevail.

[0026] The number of calibration samples, measurement values, and parameter values ​​in this embodiment are used to illustrate the value acquisition procedure; values ​​without original records are used as setting examples. In actual configuration, the terminal model, system software version, interface version, calibration service status, original records, value acquisition method, and configuration version are saved. Parameters involving the device's allowable range are read from the corresponding device documentation and firmware configuration; parameters involving service acceptance are read from the actual acceptance configuration used. Example values ​​cannot replace incompatible device limitations or service requirements.

[0027] A running task is a business processing activity being executed by the terminal. A resource object is an operating system object that hosts or is used to measure and control this activity, including processes, threads, CPU control groups, memory control groups, graphics rendering contexts, audio sessions, network sockets, and device control sessions. The task resource record stores the correspondence between running tasks and resource objects, but does not use the task name as the underlying control target.

[0028] A resource control entity is a collection of resource objects controlled by the same control interface instance and control objective, categorized by resource type, and whose control parameters cannot be set separately. A resource control entity outputs an entity identifier, resource type, member list, and control objective information, and participates in dependency analysis, resource ownership, reservation, execution, and recovery. The same process can correspond to different resource control entities on different resource types, while non-overlapping measurement ranges are used for the same resource type.

[0029] The resource control capability table is a structured record generated based on interface checks and maintenance tests. It stores allowed ranges, control granularity, readback fields, reverse actions, and capability statuses according to resource control entities, resource types, and resource control actions. Capability statuses include precisely executable, degradeable executable, and non-executable. Precisely executable means the target status can be set and read back at the granularity declared by the interface; degradeable executable means only a limited set of verified levels can be used; non-executable means the corresponding action is not allowed under current conditions.

[0030] The session dependency graph uses resource control entities as nodes and forms directed edges based on actual business calls and resource usage relationships. The session dependency set is a deduplicated set of entities obtained by starting from the front-end business root resource control entity and accessing it along the confirmed directed edges. The session dependency set is an identifier set and does not have a resource quantity unit; it is used to determine the support scope of the current business.

[0031] A scheduling snapshot is a data copy formed by measuring time, statistical windows, state validity periods, and version checks. A resource control domain is a logical ownership determined based on basic security attributes, foreground business identity, session dependencies, and reclaim eligibility; it is not a physical partition of embedded memory. The resource control domain records unique ownership, reference relationships, resource boundaries, control budgets, predicted demand, resource gaps, and corresponding versions.

[0032] Version verification records retain the original fields used for performance checks. Resource reservation records store the relationship between the supplier's recoverable quota and the unfilled gaps by the receiver. Resource recovery records store the control status before and after the action, the actual execution results, and the information required for recovery. These three types of records are used for comparing execution conditions, preventing quota reuse, and restoring existing control effects, respectively, and are not interchangeable.

[0033] The verified resource release amount is the upper limit granted based on the actual reduction in physical resource usage, the increase in available resources on the system side, and the reserved amount, determined when the measurement is valid. The actual granted amount is the amount of quota increase that has been executed and confirmed by the receiving interface. Recovery processing targets control budgets, control settings, and allocated permissions; it does not mean revoking completed calculations, network transmissions, or restoring all released cached content.

[0034] The business resource demand statistics table is grouped according to the defined business status and stores the lowest, median, and highest observed values ​​of the valid resource samples. This table is used to determine the predicted demand in subsequent scheduling and does not directly modify the underlying resource control capabilities, hard reserve boundaries, or local resource protection rules.

[0035] like Figure 1 As shown in the figure, this embodiment discloses a system resource allocation method based on partition scheduling, which includes the following steps: S1. Collect running tasks and underlying resource control capabilities, and generate task resource records, resource control entities, and resource control capability tables; construct session dependency graphs and session dependency sets based on runtime dependency evidence; and generate scheduling snapshots by combining resource measurement records. S2. Determine the unique resource control domain affiliation of the resource control entity based on the session dependency set and scheduling snapshot; determine the resource boundary, predicted demand, and resource gap respectively; generate resource control domain records and version verification records; S3. Based on the resource control domain records, filter the supply resource control entities and establish resource reservation records; generate resource recovery records before the execution of resource reclamation transactions and actions based on the resource reservation records; verify the version and execute resource control actions; determine the verified resource release amount based on bilateral measurements; complete the granting and update the resource recovery records. S4. Verify the operational status of activity services, basic support services, and supply resource control entities based on resource recovery records and operation measurement records; if verification fails, process executed actions and generate scheduling restriction records; if verification passes and recovery conditions are met, restore, verify, and update the business resource demand statistics table in batches.

[0036] In this implementation, in S1, the processor first determines which operating system objects actually occupy resources and which objects are jointly controlled by the same control target, and then establishes the correspondence between business identities and resource control entities. Running tasks are business processing activities; processes, threads, control groups, and session handles are resource objects that carry or control this activity, and both are recorded separately. Non-overlapping measurement ranges are used for the same resource type to avoid simultaneously accumulating the occupancy of processes, threads, and their respective control groups. The resource control capability table saves capabilities by entity, resource type, and action; non-executable objects still participate in dependency analysis and resource measurement. The foreground business root resource control entity is determined by the current focus and task instance records, not based on the premise that a resource control domain has already been established. The processor establishes a session dependency graph based on actual calls, data transfer, and object persistence, obtains the session dependency set through the pending access queue and the accessed list, and forms a temporary protection range for the relationships to be confirmed. Collection failure cannot be directly interpreted as dependency release; when dependency analysis cannot be completed, the generation of new recycling transactions is stopped. The scheduling snapshot combines the actual time of resource measurement, the statistical window, and the effective period of the status record, and checks the versions before and after collection. The task resource records, resource control capability tables, session dependency sets, and scheduling snapshots output by S1 serve as inputs to S2, ensuring that resource ownership, metering, and subsequent actions correspond to the same batch of verified resource objects.

[0037] In this implementation, in S2, the processor uses the session dependency set generated in S1 to determine the support scope that the current service must retain, and uses the scheduling snapshot to verify the existing status of resource objects. Entities corresponding to the basic assurance service list are first assigned a affiliation, then the affiliation of the front-end service root entity and session support entity is determined, and the remaining entities retain the reclaim eligibility flag. When the same actual control scope covers different services, the service protection level configured for each service in the local resource protection rules is read, the service protection level of each service within the actual control scope is compared, and resource control actions are restricted according to the protection requirements corresponding to the service protection level with the highest value. The budget of the entire control scope cannot be reduced individually based on the background member's identity. Shared entities are only measured once, and the increment that can be assigned to a session is determined through actual service records; indistinguishable parts are retained within the entity's unique affiliation domain. The processor separately saves the current control budget, actual resource usage, and system available resources, and uses the hard retention boundary, flexible operating boundary, and service resource demand statistics table formed by calibration to determine resource gaps, without directly treating the control upper limit as the actual resource usage. The CPU time, memory, and network transmission budget are measured separately, and graphical continuity, temperature, and power status are used for action access and verification. When generating resource control domain records, members, rules, capabilities, and dependency versions are saved simultaneously, and then a version verification record is formed that retains the original fields. The resource control domain records, resource gaps, and version verification records output by S2 are used by S3 to select supply objects, establish reservations, and check execution conditions. Historical records are not overwritten due to subsequent state changes.

[0038] In this implementation, in S3, the processor selects a resource control entity that is eligible for reclamation but is not within the current session's protection scope based on the resource control domain record generated in S2. Simultaneously, it checks the unreserved quota on the supplier and the uncovered resource gap on the receiver. Valid reservations remain occupied across scheduling cycles and cannot be reused simply because the next cycle begins. Action parameters are first determined at the interface granularity, then the supply boundary, single action limit, and remaining gap are checked; the control amount cannot be increased by rounding up. Before execution, the control status and recovery basis of the supplier and receiver are saved, and exclusive execution eligibility for the corresponding control scope is obtained through the unified resource management service. At each execution stage, the object instance, protection relationship, and version are rechecked. Actions submitted but with uncertain results remain in a pending confirmation state and are not directly released due to timeout. Consistent measurement windows are used before and after reclamation to obtain results on the entity side and system side, respectively. The verified resource release amount is determined after validity checks. The receiver's quota is increased through the actual control interface; only the effective portion confirmed by readback is recorded as the actual granted amount. The reduction in the supply-side control budget, the verified resource release, and the actual grant are recorded separately. Control budgets that are not actually granted are still associated with the supply-side recovery record. S3 outputs the updated resource recovery record, actual grant results, and remaining gap for S4 to conduct business verification, failure handling, and phased recovery.

[0039] In this implementation, in S4, the processor identifies the supplier, receiver, control fields, and action sequence involved in this adjustment based on the resource recovery record generated in S3, and continuously obtains the corresponding business operation measurement records. The verification scope includes the continuity of the activity business, the status of basic support services, and the progress of the supplier's tasks. The completion of this resource adjustment cannot be determined solely by the interface returning a success. If the verification fails, the processor first processes the receiver's temporary quota, and then restores the supplier's control settings. Actions with uncertain results must first clarify the actual status. If the restoration cannot be completed, the incomplete record is retained and related new transactions are stopped. After the verification is passed, the supplier's control settings may continue to remain in the adjusted state, so the resource recovery record still needs to be retained. Batch restoration simultaneously meets the conditions of continuous and uninterrupted operation, normal current business status, and sufficient budget after restoration. Each batch processes only one supplier entity and its corresponding grant record, and is implemented in reverse order of the actual action sequence. During the trial restoration, the state before restoration and the compensation relationship are saved. If a resource gap or abnormal business indicators are found, the batch of trial restoration is canceled, and the grant amount is not accumulated repeatedly. The business resource requirement statistics table only uses verified resource measurement records that are not subject to resource constraints. Interaction latency and service heartbeats are used for sample admission and are not considered as the quantity of resource requirements. The updated statistics table will be used in subsequent S2 processes for requirement determination, and completed transactions will still be processed based on the original resource recovery records.

[0040] like Figure 2 As shown, in one specific embodiment, S1 includes the step of: S11. Collect running task and control interface information, identify resource object instances and actual common control scope, and generate task resource records, resource control entities and resource control capability tables.

[0041] S12. Determine the current session and foreground business root resource control entities based on business focus, collect runtime dependency evidence, and generate session dependency graph, session dependency set, and temporary protection scope.

[0042] S13. Collect resource measurement records, verify measurement time, statistical window and status version, and generate a scheduling snapshot with valid flags.

[0043] like Figure 3 As shown, in one specific embodiment, S2 includes the following steps: S21. Determine the unique resource control domain affiliation based on the basic support service list, front-end business root resource control entity, and session dependency set, and handle shared entity metering and reference relationships.

[0044] S22. Based on the scheduling snapshot and the business resource demand statistics table, determine the resource boundaries, predicted demand and resource gaps for each resource type, and check the temperature, power supply and system capacity conditions.

[0045] S23. Write the resource ownership, resource boundary, resource gap and version information into the resource control domain record and generate a version verification record.

[0046] like Figure 4 As shown, in one specific embodiment, S3 includes the following steps: S31. Screen the supply resource control entities, verify the recoverable amount of the supplier and the gap that the receiver has not yet covered, and establish an effective resource reservation record across scheduling cycles.

[0047] S32. Based on the resource reservation record, form a resource reclamation transaction, determine the action parameters, execution order, target state and reverse action, and prepare the resource recovery record.

[0048] S33. Obtain execution qualification and verify version, persist resource recovery record and then execute action, determine the verified resource release amount through two-sided measurement, execute grant and update resource recovery record.

[0049] like Figure 5 As shown, in one specific embodiment, S4 includes the following steps: S41. Obtain the business operation record after the action, and verify the business continuity of the activity, the status of basic support services, and the progress of the supplier's tasks.

[0050] S42. When verification fails or the execution result is abnormal, process the executed actions according to the resource recovery record, and save the scheduling limit record and the incomplete recovery status.

[0051] S43. When the recovery conditions are met, perform recovery and verification in batches, and update the business resource requirement statistics table based on the valid resource samples.

[0052] In one specific embodiment, in S11, the unified resource management service reads resource objects from the task management interface, control group interface, audio service interface, network connection interface, and device session interface. The task resource record at least stores the current startup identifier, running task identifier, resource object instance identifier, parent resource object instance identifier, current session identifier, service type, resource type, control target, occupancy record, and collection time. When a service has not yet determined its current session, it retains an unassociated state, and the same session is not presumed based on the same process name.

[0053] Resource object instance identifiers contain information that distinguishes object re-creation. Process instances are determined by the process identifier and creation time, control group instances by the control target and creation generation, and sockets and device sessions acquire unique instance identifiers upon creation. The current startup identifier is regenerated after each startup. When a process number, file descriptor, or control target name is reused, the old and new instances are recorded separately, and old recovery actions cannot be applied to the new instance.

[0054] Resource control entities are formed separately according to resource type. Objects using the same interface type but with different control objectives are created as separate entities. Objects that accept the same control objective and share common constraints and cannot have their parameters set separately are merged into one entity. When parent and child control groups exist, resource usage is measured using non-overlapping leaf-level ranges, and parent records are only used to check the total budget and hierarchical constraints. Shared pages or shared buffers are measured according to actual accounting attribution, and resource usage should not be repeatedly increased due to multiple processes holding references.

[0055] The resource control capability table stores entity identifiers, resource types, interface instances, control objectives, parameter ranges, measurement granularity, readable status, permitted actions, reverse actions, and capability versions. If an entity's central processing unit (CPU) action is unexecutable, it does not affect its already verified network control capabilities; capability status is determined separately for resource type and action. Actions where the member scope cannot be determined, the status cannot be read back, or a verifiable recovery path cannot be formed are recorded as unexecutable.

[0056] Initial capability verification is performed using test objects during the initialization or maintenance phase. The processor first checks the existence, permissions, and allowed parameters of the interface, then makes a limited number of adjustments according to the granularity supported by the interface, saving the request value, readback value, target object, and recovery result. Actions that can be executed and recovered at the supported granularity are marked as precisely executable, while actions that only support a limited range are marked as degradeable. During runtime, the processor reads the already formed capability records and checks the version, without repeatedly writing test parameters in each scheduling cycle.

[0057] The maximum waiting time for capability detection is set to 300ms. This value is derived from the combined calibration of interface response time and scheduling processing time during the maintenance phase. Specifically, the check is repeated under both idle and heavy workload conditions, recording the time from request submission to a valid response, and separately recording the result processing time. The sum of the larger values ​​is then used. In the example setting, the maximum interface response time is 218ms, and the scheduling and processing margin is 82ms, therefore 300ms is used. If this time is exceeded, the check is recorded as incomplete, but this does not mean the request did not occur.

[0058] Newly created objects can participate in dependency protection before their capabilities are confirmed, but they cannot become supply objects. When object members, control targets, or interface permissions change, the member records and capability versions are updated. If only the member timestamp is updated but the member and capability remain unchanged, the capability version is not increased to avoid the sampling process itself causing all pending transactions to fail.

[0059] In S12, the processor determines the root resource control entity for the foreground service based on the display, audio, camera, and user interaction focus records, and then generates the current session identifier. The current session identifier consists of the current startup identifier and a locally incrementing sequence number. When multiple valid foreground sessions exist, the root entity and session state are saved separately, and the resource control domain affiliation is determined after dependency analysis is completed.

[0060] Runtime dependency evidence must at least store the session identifier, dependent instance, dependent instance, evidence type, establishment time, most recent acknowledgment time, validity period, and acquisition status. Inter-process calls are directed according to the initiator and the actual service provider; graphics buffers are directed according to the data user and the provider; audio links are directed according to the correspondence between the session user and the audio processing service. Sockets, shared memory, and file descriptors are linked through creation, transfer, use, and release records to define relationships.

[0061] When only two objects are found referencing the same shared object, but the business direction cannot be determined, a temporary protection relationship with an uncertain direction is formed. The processor includes the relevant endpoints in the protection analysis, and does not directly record relationships with unclear directions as confirmed directed edges. Session handles that are continuously held and actually used continue to provide evidence through persistence checks, without requiring the generation of new communication messages in each cycle.

[0062] A directed edge is marked as pending confirmation when it first appears. It becomes confirmed when it exists for two consecutive valid collection periods. This confirmation period is derived from a comparison of maintenance records for one-time and continuous business calls. In the example configuration, a one-time query only appears in one period, while continuous audio / video service relationships span two or more periods; therefore, two periods are used. If a pending confirmation edge is not discovered within a valid period, the consecutive occurrence count restarts.

[0063] An edge that has been confirmed to be undetected for three consecutive valid collection cycles is considered invalid. These invalidation cycles originate from maintenance records that continuously rely on temporary missed reports. In the example configuration, the longest temporary missed report is two cycles; adding one cycle results in a three-cycle limit. An edge awaiting confirmation that has been undetected for three consecutive valid collection cycles is also considered invalid. Cycles with failed collection, lost events, or unverifiable object identities are not accumulated as non-existent counts. New resource reclamation transactions are stopped when collection integrity is insufficient.

[0064] The processor adds the foreground business root resource control entity to the queue to be accessed. It retrieves one entity at a time, reads its confirmed outgoing edges, adds unvisited dependent entities to the queue, and saves the arrival paths. Entities that have already been accessed are not added again. A session dependency set is generated when the queue is empty. In cases of circular dependencies, repeated access is terminated using the accessed list, and no further strong connectivity groups are established.

[0065] The processor additionally generates temporary protection scopes along the relationships to be confirmed and those already confirmed; relationships with uncertain directions are protected according to their associated endpoints. This scope is used for filtering, without expanding the evidence conclusions of the confirmed set using relationships to be confirmed. Both sets store the version of the dependency graph used.

[0066] The maximum traversal depth is set to 6 levels. This value is derived from the maintenance calibration of the complete dependency path of the target business and the traversal time. In the example setting, the longest required path for 200 complete records is 5 levels. After adding 1 level of processing margin, 6 levels are used. If there are still valid outgoing edges when the maximum is reached, the dependency analysis is recorded as incomplete. No new recycling transaction will be generated for this session in this cycle. Established protection relationships will be retained, and subsequent processing of unresolved relationships will continue.

[0067] The current session ends when the business root exits, or when focus has been released and the relevant surviving dependencies no longer exist for three consecutive valid periods. This waiting period uses the aforementioned dependency false negative calibration result. Before a new business acquires focus or a managed service delivers a session object to it, it first registers the protection relationship with the unified resource management service; if the object already has reclamation restrictions, it first processes the necessary recovery or resource arrangements, and if the protection registration is not completed, the object is not recorded as available for use by the new business.

[0068] In S13, the processor uses a 1-second scheduling cycle and a 100-ms sampling interval, both parameters derived from multi-condition resource change calibration. During the maintenance phase, standby, video playback, video call, interface interaction, and device control services are run, with each type continuously recorded for 30 minutes. This recording duration covers the startup, continuous operation, and service switching phases in this calibration plan. The minimum attention surge duration for the example is set to 250ms. Among the candidate intervals of 50ms, 100ms, and 200ms, 100ms can obtain at least two valid observations and meet the acquisition overhead requirements; therefore, a scheduling check cycle consists of 10 sampling intervals.

[0069] CPU usage is obtained from high-resolution runtime counts, while the system side obtains it from runtime and idle time records within the same online core range. Each 100ms statistical window stores the start and end cumulative counts, calculates the cumulative core time within the window, and then converts it to the time corresponding to a 1s scheduling cycle. The original time unit used by the counter is retained in the record; low-resolution statistical results cannot be overwritten with finer values ​​not actually measured. This window becomes invalid if event records are lost, the core range changes, or the counter is reset.

[0070] Network measurements are obtained from the transmit counters of the same locally controlled egress point. The transmit rate is calculated based on the actual length of the statistical window and recorded in Mbps. Since the supplier and system sides use the same encapsulation level and byte metering caliber, the amount of data sent by the application cannot be directly compared with the amount of data already transmitted from the egress point.

[0071] Memory measurements are recorded in bytes and pages, with the unit uniformly set to MiB. 1 MiB corresponds to 1,048,576 bytes; this conversion is determined by the unit definition. The provider records the actual resident usage of rebuildable caches, while the system records the actual free space within the same memory management range. System reservations and other transaction usage are also stored. Virtual address requests are not considered actual resident usage, and reclaimable cache already included in available space is not repeatedly listed as new provisioning.

[0072] The time of the last unified sampling trigger before the end of each scheduling cycle is used as the snapshot baseline time. The upper limit of time deviation is set to 20ms, which comes from cross-interface sampling deviation and thread wake-up delay calibration. In the example setting, the maximum interface deviation of 100 sets of synchronous sampling records is 12ms, and the additional wake-up delay is 8ms, so 20ms is used. The number of sampling groups is determined by the maintenance plan and is used to cover the interfaces and load conditions listed in this document.

[0073] For CPU and network records, alignment is performed using the end time of the statistical window, and both windows must be of equal length. Memory, temperature, and power records use the actual generation time. When the interface returns cached values, the original generation time must be used; the read time cannot be used as a substitute. Session dependencies and control capabilities are periods of validity; their validity period must cover the baseline time, and re-generating the call at the baseline time is not required.

[0074] The scheduling snapshot saves the snapshot identifier, baseline time, task record version, capability version, dependency graph version, session dependency set, each measurement value, statistics window, measurement source, and validity flag. Member, dependency, capability, and rule versions are read before and after generation; if inconsistencies exist, the current combination result is discarded. Snapshots are invalid if necessary measurements are missing, time is reversed, or the allowable deviation is exceeded.

[0075] Graphical queue status, temperature, and power data are used for corresponding transaction admissions. If the current firmware cannot provide valid data, it will not be replaced with a zero value. Invalid snapshots are not used to generate new transactions, but actions already performed are still processed according to resource recovery records. If the state required for recovery cannot be confirmed, incomplete records are retained and related append actions are stopped.

[0076] In one specific embodiment, in S21, the processor first reads the list of basic protection services from the local resource protection rules. This list is formed based on the terminal's startup services and basic product function configurations, and at least covers input distribution, system interface, basic network connectivity, temperature monitoring, and power monitoring. The list remains unchanged in the current rule version, and is updated to form a new rule version.

[0077] Entities corresponding to basic support services are assigned to the basic support resource control domain, front-end business root entities are assigned to the activity business resource control domain, other entities in the session dependency set are assigned to the session support resource control domain, and the remaining entities are assigned to the reclaimable resource control domain. Each entity in the reclaimable resource control domain has its own reclaim eligibility; entities that are not executable, temporarily protected, or otherwise prohibited from reclaiming are not allowed to obtain reclaim eligibility based on domain name.

[0078] When the same entity meets multiple conditions, its unique affiliation is determined in the order of basic assurance, active services, session support, and reclaimability. Audio basic routing services and call audio processing services can be affixed separately if they can be distinguished by different actual control objectives; if they cannot be distinguished and are jointly controlled, the entire entity adopts the basic assurance requirements. Camera, graphics, or network services use the same processing; members that cannot be separately controlled cannot be separated merely in logical records.

[0079] The service protection level is configured according to the service type by the local resource protection rules. In this embodiment, basic protection services use Level 4, real-time audio and video use Level 3, other foreground interactions use Level 2, and background tasks that can be deferred use Level 1. This level configuration is derived from the terminal service priority configuration. The service protection levels are compared according to their numerical values, with Level 4, Level 3, Level 2, and Level 1 corresponding to the protection order from first to last. When different protection requirements are involved within the same actual control area, the service protection levels of each service within that actual control area are compared, and resource control actions are restricted according to the protection requirement corresponding to the service protection level with the highest numerical value. When the service protection levels are the same, they are processed according to the order of valid request time, and then the order is determined by the session identifier. The service protection level determines the conflict handling order, but does not replace resource boundary checks.

[0080] The shared entity first measures the total resource quantity once, and then allocates attributable increments based on call, buffer, and send records with session identifiers. Occupancy that cannot be distinguished by session is retained in the entity's unique attribution domain and is not replicated based on the number of sessions. Basic requirements use calibration records when the service does not handle current business increments; attributable occupancy generated by new sessions is stored separately.

[0081] For example, a shared service has a basic requirement of 60 MiB. Two sessions generate attributable increments of 20 MiB and 30 MiB respectively, resulting in a total entity requirement of 110 MiB. The two sessions only store reference relationships and their respective increment sources. When a resource control domain is aggregated, this entity's total requirement is only counted once. If increments cannot be reconciled with the entity's total requirement, the split results are not used to increase the global requirement; instead, the entity's total requirement and its undifferentiated state are retained.

[0082] In S22, the processor reads the current control budget, actual resource usage, and available system resources. The current control budget is the active CPU time quota, managed memory allocation budget, or network transmission budget. Actual resource usage is measured, and available system resources are used to determine if the current grant has sufficient margin. The supply limit is calculated using the control budget, and the release verification is calculated using changes in actual usage.

[0083] CPU resources are recorded as cumulative core time within 1 second. The theoretical cumulative time for 4 online cores is 4000ms. The actual manageable budget should deduct interrupts, kernel overhead, and other unrecoverable costs, and check the core affinity range and parent control budget. Control quotas are usage limits and are not directly equal to the minimum actual execution time. Hard reserve boundaries represent budget boundaries that the scheduler cannot actively reduce; their applicability must be confirmed through operational verification.

[0084] In this example, the CPU control cycle is 100ms, derived from the actual control interface configuration and verified through maintenance. This translates to an 800ms budget per second, corresponding to 80ms of cumulative core time per control cycle; a 1320ms budget corresponds to 132ms of cumulative core time, which can be shared by multiple online cores. Control parameter conversions use the recorded actual cycles; values ​​from a 100ms cycle cannot be directly used as a 1s budget.

[0085] Hard retention boundaries are formed through a limited number of tiered derating calibrations. Each time, one resource of an entity is adjusted, and the level that last passed verification across active services, basic services, and task progress is recorded. This process is repeated under target temperature, power, and concurrency conditions. The larger of the lowest pass values ​​for each state is used, plus the retention amount determined by additional load calibration. In the example configuration, the lowest pass value for the basic service CPU is 684ms, and the additional load retention is 36ms, forming a 720ms boundary; the lowest pass value for the session support service is 342ms, which, after increasing by 18ms, forms a 360ms boundary.

[0086] The hard memory reservation boundaries employ the same step-by-step calibration process. In the example configuration, the minimum pass value for basic services is 416 MiB, which increases to 430 MiB after adding 14 MiB of reservation; the minimum pass value for session support services is 168 MiB, which increases to 180 MiB after adding 12 MiB. The reservation amount comes from additional load records corresponding to the target state and is not arbitrarily reduced by remote resource policies.

[0087] The elastic operation boundary is determined based on the results of background tasks completing within the allowed timeframe. During the maintenance phase, the budget is progressively reduced, recording task completion volume, queuing status, and impact on basic services. If stagnation or exceeding the timeframe occurs, the budget reverts to the most recently approved tier. In the example configuration, content prefetching passes with a 500ms budget but fails with a 480ms budget, so 500ms is used; cache maintenance passes with a 120MiB budget but fails with a 112MiB budget, so 120MiB is used; log upload passes with a 0.6Mbps budget but fails with a 0.5Mbps budget, so 0.6Mbps is used.

[0088] The aforementioned allowable completion period is read from the specific business task record, and the calibration hold time should cover the task's progress judgment interval. The maintenance plan should check for at least 3 consecutive scheduling cycles before judging the gear, and this number comes from short-term resource fluctuation calibration; if the allowable period of the task itself is longer, continue to observe until the task progress can be judged, and do not assume that long-term tasks have met the requirements after observing for more than 3 cycles.

[0089] The predicted demand is obtained from the business resource demand statistics table that matches the current business status, and compared with the current effective demand observation value and the corresponding protection boundary. The larger value is adopted and aligned upwards at the interface granularity. If there is no matching statistics table, the initial calibration record of the same status is used; if the initial record does not exist either, the budget is not added or reduced based on the lower demand value of other businesses, the existing control status is retained and the pending calibration status is registered.

[0090] This implementation uses the control budget already in effect for the activity as the current available budget. Unallocated quotas and safety margins are separately recorded and reserved within the system, and are not reused in this supply recovery process. The portion of predicted demand exceeding the current available budget is recorded as a resource gap; after granting, the confirmed quota increase is deducted to obtain the current remaining resource gap. Existing reservations only indicate gap coverage relationships that have not yet been completed and are not counted in advance as actual grants.

[0091] When the total hard-reserved amount in each resource control domain exceeds the manageable capacity, no new reclamation or grant plans will be generated in this round. If the supply objects are insufficient, the control granularity cannot meet the remaining gaps, or the interface conditions are not met, the unmet gaps and their reasons will be retained, and the gaps will not be filled by increasing the reserved amount. Different resource types will be handled separately; memory, CPU time, and network bandwidth cannot be added together.

[0092] The temperature protection value is set to 85℃ in this example, provided that the corresponding device datasheet and firmware configuration support this measurement point limit. The temperature margin required for additional resources is set to 5℃, which is obtained by combining a large short-term temperature rise of 4℃ and a measurement error margin of 1℃ during maintenance testing. The value will be recalculated if the actual device limit or measurement point does not match; if the temperature conditions are insufficient, new grants that may increase the processing load will be prohibited, but necessary protection processing will continue to be performed.

[0093] The power margin is determined by comparing the power supply capacity and actual power at the same input measurement location of the terminal. The margin required for additional resources is set at 500mW, which comes from the 400mW peak increment and 100mW measurement and response margin in the example. Power conversion losses are handled during power supply capacity conversion and are not deducted repeatedly. When there is no valid measurement or verifiable firmware data, the adapter nameplate power is not used to replace the real-time margin.

[0094] In S23, the processor writes the current session identifier, unique ownership, reference relationship, current control budget, actual occupancy record, hard reserve boundary, elastic operation boundary, predicted demand, resource gap, snapshot identifier, and rule version to the resource control domain record. A new version is obtained when the record is published; subsequent changes form new records, without overwriting historical versions already used in transactions.

[0095] Version verification records retain dependency graph versions, resource control domain record versions, capability versions, rule versions, object instances, and member lists. Members are sorted by resource object instance identifiers, and fields are stored in a fixed order and type. During verification, each field and corresponding version in the version verification record that retains the original fields is compared item by item with the current state. The member list is compared according to resource object instance identifiers, and consistency is presumed if the application names are the same.

[0096] The allowed duration of a scheduling snapshot is one scheduling cycle, which is calibrated using a 1-second cycle derived from S13 load changes. If a transaction exceeds the snapshot's validity period, a new snapshot is collected and the corresponding S2 processing is executed; simply updating the time field and continuing to use the old value is not permitted. A new version is released when resource domain ownership, protection boundaries, or effective budgets change; if only historical sampling records are appended without changes to the above content, the control domain version will not change due to an increase in the number of records.

[0097] For cross-phase transactions, the initial version verification record remains unchanged, while confirmed control changes within the transaction are saved separately. Subsequent phases generate new phase verification records based on the current state, verifying expected changes within the transaction and external changes. Phase verification uses the corresponding S1 and S2 handlers to obtain current information, ensuring that budget changes caused by resource reclamation are not disguised as still valid as the original state.

[0098] In one specific embodiment, in S31, the processor reads entities in the reclaimable resource control domain that are eligible for reclamation. Objects within the session dependency set, temporarily protected objects, objects with valid scheduling constraint records, and objects within the same control scope that still have unrecovered records are not included in this provision. Objects are also skipped if the interface does not support the corresponding granularity, object instances change, or the provision budget is not higher than the elastic operating boundary.

[0099] For the remaining candidates, the supply limit is the portion of the current control budget that exceeds the elastic operating boundary and has not yet been occupied by other valid reserves. The single-action limit also needs to be checked. In this example, the CPU single-action limit is 300ms, derived from a maintenance test where a 320ms adjustment passed, a 340ms adjustment failed, and a 20ms margin was reserved for a smaller increment. The memory single-action limit is 160MiB, derived from a 176MiB pass, a 192MiB failure, and a 16MiB margin. The network single-action limit is 0.9Mbps, derived from a 1.0Mbps pass, a 1.1Mbps failure, and a 0.1Mbps margin.

[0100] Historical statistics for candidate objects only use records of the same object instance, resource type, action, business type, and rule version. The historical verification pass rate is the proportion of successful attempts out of valid attempts, and the rollback count uses the same statistical range. Historical sorting is enabled after 10 valid attempts are made. This number is determined by the repeat verification plan for each type of action during the maintenance phase and does not indicate that the statistical confidence requirement for unverified actions has been met.

[0101] Candidates with valid statistics are first sorted by pass rate from highest to lowest. If the pass rates are the same, they are then sorted by the number of backtracks from lowest to highest. If they are still the same, they are sorted by entity identifier. Candidates with insufficient history are listed separately by entity identifier, without interpreting the absence of records as all successes or all failures. For example, a record with 9 successes out of 10 valid attempts is 90%, and a record with 8 successes is 80%.

[0102] Before making reservations, align the target action with the interface level. For discrete interfaces, the processor enumerates the currently allowed target levels, calculates the budget reduction for each level, and retains levels that do not exceed the supply limit, single action limit, and currently uncovered gaps. From these, the level with the largest reduction is selected. If the remaining gap is 14ms but the interface can only be adjusted in 20ms increments, skip the interface and do not establish a 20ms reservation.

[0103] The Unified Resource Management Service reads the supplier's quota, receiver's gap, and reserved registration version within a short-term mutually exclusive processing scope. After verification, it performs version comparison and writes the data to the reservation record. Supply reservations and receiver reservations are completed within the same processing scope. If the comparison and exchange fail, the data is read again; old gaps cannot be reused. Only after the corresponding reservation is written to the transaction persistence area is the action execution allowed.

[0104] The exclusive scope of effective reservations is determined by the launch identifier, entity instance, and resource type. The scheduling cycle identifier is used to track the generation time. Records store the transaction identifier, supplier, receiver, resource type, reservation amount, pre-control budget, version verification record, and status. When different suppliers fill the same receiver gap, they share the receiver gap record; unfulfilled reservations are first deducted from the still-coverable portion.

[0105] The waiting period for execution shall not exceed the duration of the scheduling snapshot; this limitation stems from the validity period of the S23 snapshot. Reservations can be cancelled upon the expiration of the waiting period and confirmation that no underlying action has been submitted. Once an action has been submitted, the record will not be released directly according to the waiting period. Objects that have passed verification but whose supply control status has not yet been restored retain an unrestored flag and cannot be supplied again in subsequent cycles according to the original pre-control budget.

[0106] In S32, each resource reclamation transaction processes one resource from a supply entity and includes the corresponding grant action from the receiver. The transaction saves the reservation identifier, object instance, resource type, action order, preconditions, pre-control state, target state, single-transaction limit, interface granularity, execution period, and reverse actions. Multiple supply objects are processed sequentially according to the actual execution results; when gaps need to be filled, snapshots and version records are retrieved again.

[0107] The central processing unit (CPU) executes actions through the actually configured control group quota interface. The CPU reads the control cycle, current quota, parent limit, and core range, converts the scheduling cycle budget into interface parameters, writes them, and then reads back the cycle and quota. Recovery actions use the previously recorded original quota and cycle. Interface states without upper limits are saved as independent state records and are not considered for quantitative supply until the limited budget maintenance configuration is completed.

[0108] Memory operations are performed by the managed cache management interface. A background process registers cache block identifiers, actual capacity, residency status, reference status, reconstruction source, incomplete write status, and most recent usage time. The processor selects only cache blocks that are not referenced by the current session, are not locked, have no incomplete writes, and can be reconstructed from existing business data or local files. These are processed in order of most recent usage time, from earliest to latest; if times are the same, the order is determined by the cache block identifier.

[0109] Before modifying the capacity limit, the cache manager saves the original and target limits. It performs a new budget check on new cache requests and then releases eligible cache blocks. Cache blocks involving shared references, still in use, or whose source has expired are skipped. Release is performed at the granularity of pages or cache blocks actually supported by the interface; blocks exceeding the action limit cannot be released simply to reach a reserved value. The release results are saved as an actual processing list and then verified by both the entity and system sides.

[0110] Memory recovery only restores the maximum capacity and subsequent allocation permissions. Subsequent services will rebuild the cache as needed. Released cache will not immediately reoccupy the same physical pages due to the maximum capacity recovery. Other memory pressure mechanisms in the terminal will continue to operate according to the firmware rules. If a related object exits or an abnormal memory state occurs, the current transaction will enter a status confirmation phase and will not continue to grant permissions according to the original instance.

[0111] Network actions affect the transmission budget of the same locally controlled exit. The supplier and receiver use the same exit and statistical caliber, modifying and reading back the transmission budget through queues or corresponding control interfaces. In this implementation, network bandwidth represents local transmission control capability, not end-to-end network capacity. This measurement is invalid when the exit is switched, the shaping capacity changes, or the statistical level changes.

[0112] The upper limit for resource control action execution wait time is set to 500ms, a value derived from the control status readback calibration during the maintenance phase. In the example setting, the longest stable readback time for 50 interface tests is 382ms, with a scheduling and processing margin of 118ms, combined to 500ms. The number of tests is determined by this maintenance plan, and the results of each interface are saved independently; the test results of one interface will not replace those of other interfaces.

[0113] Before execution, a resource recovery record is generated, saving the supplier instance, current control state, target state, reverse action, action sequence number, and action generation. When the amount to be granted by the receiver is not yet determined, the receiver instance and current state are saved first. The corresponding target state is persisted only after the amount to be granted is determined. The corresponding underlying action is not committed until the resource recovery record is persisted.

[0114] Transaction status includes pending execution, executing, result pending confirmation, pending verification, verification passed but not recovered, recovering, recovered, cancelled, and pending maintenance. A transaction is considered cancelled when no action has been performed and the preconditions have failed; transactions with existing effects cannot be directly recorded as cancelled or recovered.

[0115] In S33, the Unified Resource Management Service acquires exclusive execution rights over the same actual control scope, comparing object instances, members, dependency protection, control capabilities, local rules, and current control values. Write requests to managed control interfaces are uniformly executed by this service. If other writers cannot be prevented from modifying the same control target, or if the required readback information cannot be obtained, the corresponding object will not participate in provisioning.

[0116] Within the same system measurement scope, the resource management service serially executes actions that alter resource status, such as reclamation, granting, and restoration. Data collection can continue, but other transactions cannot share the system increments before and after this measurement. When new business focuses, member migrations, and managed dependency registrations arrive, the protection status is updated first, conflicting actions that have not yet been executed are stopped from being committed, and executed actions are processed according to records.

[0117] Three complete statistical windows are acquired consecutively before the action. This number comes from the single deviation processing configuration in the control action noise calibration. Each window is 100ms long, derived from the S13 sampling calibration; therefore, the pre-action statistical phase occupies 300ms. Instantaneous values ​​in memory are acquired at the end of the corresponding window, and the CPU and network use the window's cumulative value. The three valid values ​​are sorted, and the median value is taken as the pre-action state.

[0118] After the supply action is completed, wait 200ms. This value comes from the resource state stabilization time calibration during the maintenance phase. In the example setting, the longest time for resource changes to enter the baseline allowable fluctuation range is 146ms, and after adding a 54ms scheduling margin, 200ms is used. The stable state is confirmed by continuous observation that it no longer exceeds the baseline fluctuation range. If the waiting period ends but the conditions are not met, the requested amount is not recorded as the released amount.

[0119] After stabilizing and waiting, obtain three complete windows with the same caliber again to form the post-action state. Sort the values ​​before and after the action and take the median value. Then, subtract the actual occupancy after the action from the actual occupancy before the action to obtain the actual reduction in occupancy on the entity side. Subtract the available quantity before the action from the available quantity after the action to obtain the increase in available quantity on the system side.

[0120] Measurement deviation thresholds are set independently for each resource type. The CPU threshold is 40ms, the memory threshold is 32MiB, and the network threshold is 0.1Mbps; all three values ​​are derived from paired baseline measurement calibration. Specifically, when this scheduling action is not executed, 300 sets of bilateral change records within the same window are collected. The absolute value of the difference between the two sides is calculated and sorted, using the 99th percentile (item 297) according to the local measurement acceptance configuration, and then aligned upwards according to the measurement granularity.

[0121] In the example settings, item 297 represents 39.2ms, 31.3MiB, and 0.094Mbps. These thresholds are obtained by aligning upwards to the 1ms, 1MiB, and 0.01Mbps values ​​in this measurement configuration. The percentile positions and number of sampling groups are derived from the measurement anomaly screening configuration during the maintenance phase, used to form this equipment configuration, and are not interpreted as indicating that all external changes have been excluded.

[0122] When the change on the entity side or system side is negative, a required measurement is missing, an object instance changes, or the absolute value of the difference between the two sides exceeds the corresponding threshold, the verified resource release amount is recorded as zero. If the change in non-target load exceeds the allowable deviation for the same type of resource, or if other control actions occur within the statistical window, the measurement will not be granted. A deviation not exceeding the limit only indicates that the current verification rule is met; it does not prove that the resource change was entirely caused by this action.

[0123] When the measurement is valid, the minimum value among the actual reduction in physical occupancy, the increase in available resources on the system side, and the reserved amount is taken, and aligned downwards according to the granularity of the receiving interface to obtain the verified resource release amount. The control parameter readback reduction is used to check whether the action conforms to the reservation, and the actual reduction in occupancy is used for resource verification. The two types of values ​​are stored separately.

[0124] Before granting, reread the current remaining resource gap and other valid reservations, and verify the system availability, resource protection boundaries, and recipient instances. Take the smaller of the verified resource release amount and the remaining gap that the current transaction can currently cover, and form the amount to be granted at the interface granularity. If the recipient has exited, the business status has changed, or the latest boundary does not allow granting, the previous amount will not be used.

[0125] Central processing unit (CPU) grants are executed by increasing the receiver's control group quota; memory grants are executed by increasing the allocation budget of the receiver's managed buffer or cache manager; network grants are executed by increasing the receiver's transmission budget at the same controlled exit. Each action saves the pre-control state and target state, persists them, writes them to the interface, and then reads back for confirmation. Actual memory allocation still checks the budget and allocation result sequentially; an increase in budget does not necessarily mean that an equivalent number of physical pages have been moved.

[0126] Increases in the credit limit that have already taken effect and been confirmed are recorded as actual granted amounts. In cases of partial granting, the actual difference is recorded, not the entire requested value. After granting, a new effective budget and remaining shortfall record are published. Unused portions of the corresponding receiving reservations are released after confirmation that no further actions are pending; all control changes already made by the supplier remain in the resource recovery record.

[0127] When a supplier reduces its 300ms budget but actually grants 286ms, the additional 14ms control budget remains associated with that supplier's recovery record and is not considered unallocated space that can be reused by other transactions. This value does not indicate that the 14ms of additional system availability time has been verified; it is only used to record complete changes in supplier control. Memory and network use the same separate accounting method.

[0128] Even if the resource release is verified to be zero, the supply action may still have changed the control settings. Therefore, the control settings should be restored based on the resource recovery record, and the results verified. If the recipient fails to grant the resource or the result is uncertain, the current status of the recipient should be confirmed before processing the supplier's recovery. If a clear result cannot be read, the result should be kept pending confirmation, and the corresponding exclusive occupancy should not be released prematurely.

[0129] The monitoring period is set to 5 seconds, determined by the transaction time budget for this example. The remaining 4 seconds consist of 300ms for pre-action measurement, 500ms for supply control, 200ms for stabilization waiting, 300ms for post-action measurement, 500ms for receiving grants, 2 seconds for feedback verification, and 200ms for log processing. An additional scheduling cycle buffer is added to make the 5-second period. This period is used to trigger status confirmation and is not a period for discarding incomplete records.

[0130] When a low-level action exceeds its time limit, the corresponding action generation becomes invalid, subsequent requests are stopped, and the system waits for submitted requests to complete or for cancellation confirmation before rereading the control state. If an interface cannot be cancelled and may take effect late, it remains in an exclusive state; subsequent recovery is only performed after confirming that no old requests that may still be effective exist. Records of unrecovered supplier control states can be retained across multiple scheduling cycles and are not automatically cleared during the aforementioned execution monitoring period.

[0131] In one specific embodiment, in S41, the processor initiates a 2-second feedback verification window after each actual grant is completed. This value comes from the service link stabilization time calibration. In the example setting, the maximum time for the target service to reach stable output is 1.4 seconds, and then an observation period of 600ms is formed, creating a 2-second window. Before entering the recycling process, the original service status is checked. If the original status is abnormal, a new recycling test is not used to determine whether the abnormality was caused by the supply object.

[0132] Graphical continuity is determined based on the display cycle time required by the service, the submitted frame sequence number, and the actual rendering time. When no new frames are continuously rendered, the count is based on the frames that should have been rendered but were not, comparing not only the numbers of already arrived frames. This example allows for no more than two consecutive missing frames; this value comes from the acceptance configuration for a 30 frames per second service. Other frame rates and service modes use the corresponding configurations.

[0133] Audio interruptions are determined based on the number of submitted samples, the audio sampling rate, and the playback completion time. When an underload occurs, start and end events are recorded. In this example, the maximum audio interruption time is 20ms, a value derived from the voice call acceptance configuration. Events are recorded using a monotonic clock at the time of occurrence; the 100ms aggregation period does not replace the time resolution of the audio interruption event.

[0134] The local interaction response latency begins when the terminal receives a valid input event and ends when the corresponding interface confirmation result is actually displayed. This example has a maximum of 120ms, a value derived from the local interface interaction acceptance configuration. The duration of cloud-based recognition, remote device execution, or network service completion is recorded separately and is not combined with the local confirmation latency.

[0135] Input distribution and system interface heartbeats are generated after the corresponding service actually processes and checks the request. This example allows a heartbeat interval of no more than 500ms, a value derived from the basic service stress acceptance configuration. If the independent timed thread is still running but the actual business queue has not been processed, no heartbeat for successful processing by the corresponding service will be generated.

[0136] Network status is checked based on the egress points used by the current service and the actual permitted detection methods. Services requiring network access must complete at least one valid local connectivity confirmation within a 2-second window. This condition is derived from the local network acceptance configuration and can utilize valid responses from existing connections; blocking certain probe packets by the gateway will not be directly interpreted as resource failure. Services allowed offline will have their corresponding flags marked as inapplicable.

[0137] The supplier simultaneously checks that the control budget is not below the elastic operating boundary and that background tasks are still making progress within the allowed timeframe. Log uploads check the amount to be sent and the amount completed; content prefetching checks completed data and remaining deadlines; and cache maintenance checks processing progress and request responses. If the supplier's progress does not meet the task recording requirements, verification will fail even if the activity is temporarily normal.

[0138] If any applicable metric within the verification window fails to meet its corresponding configuration, or if a required measurement is missing, the transaction will not be recorded as verified successfully. If all applicable metrics pass, the transaction is recorded as verified successfully but not recovered, and records of supplier restrictions and resource recovery for both parties are retained. The window result, the threshold version used, and the original event log are all saved together.

[0139] In S42, the processor first determines which actions have been executed, which have not yet been executed, and which results are pending confirmation. Actions that have not yet been executed are cancelled, actions with pending confirmation are processed according to S33, and actions that have been confirmed are restored in reverse order of their actual execution. If the receiving party has increased its budget, the temporary allowance is processed first, and then the supplier's control settings are restored to prevent both parties from retaining the same budget simultaneously.

[0140] When withdrawing temporary memory allocations, first prevent the creation of new managed allocations under that allocation, then check whether existing allocations can be released normally. If reducing the budget would intrude on currently unreleaseable allocations, retain the pending recovery state and wait for normal business release, without terminating the process to fulfill recovery conditions. If necessary, notify the business to use the degraded processing methods already registered in local rules; degraded methods not registered will not be temporarily generated by the scheduler.

[0141] Before performing a recovery, verify the object instance and the current control value. If the current value is already equal to the state that this action generation needs to restore, record the complete state without rewriting it; if the current value is equal to the expected post-control state, execute the corresponding reverse action; if the current value belongs to other legitimate updates, stop overwriting old values ​​and re-verify incomplete relationships according to the current version. If the original object has already exited, do not restore to a new object with the reuse number.

[0142] Idempotency identifiers include transaction identifier, object instance, resource type, action sequence number, action generation, and action direction. When the same generation receives a request repeatedly, it is processed only once. If a recovery attempt fails and the control action is re-executed, the action generation needs to be increased and the new before-and-after states saved. Subsequent recovery attempts will not be skipped by the completion flag of the old generation.

[0143] The recovery interface wait time limit is set at 500ms, a value calibrated using the response time of similar S32 interfaces. If the wait time limit is exceeded, the result remains in a pending confirmation or recovery in progress state, and new transactions within this control range are stopped. If an available recovery interface cannot be confirmed, it is marked as pending maintenance; the incomplete state is not written as recovered. If the basic protection service remains abnormal, additional resource adjustments are stopped, and the existing security boundaries are maintained by the locally configured protection handling.

[0144] The scheduling constraint log stores entity instances, resource types, actions, service types, failure indicators, generation time, duration, rule version, and related transactions. When the impact of a specific action cannot be distinguished, the log stores the combination of actions involved, and does not list any single object as a confirmed cause of failure. External events such as network disconnection, service termination, or temperature protection are logged separately.

[0145] The initial timeout is set at 30 minutes, a value derived from the observation range of one round of task changes in the background task status change calibration. In the example scenario, log upload, content prefetching, and cache defragmentation complete a distinguishable status change within 30 minutes, hence this observation period. After the timeout expires, the current object instance, business status, capabilities, and rules are re-examined; only if the supply conditions are met is a retry allowed.

[0146] Automatic retries will stop if the same object instance, action, business type, and rule version fails twice consecutively. This number of retries is derived from the repeated failure handling configuration during the maintenance phase to avoid repeatedly applying the same disturbance. When the object or rule version changes, old records are retained. The new version will re-complete the capability and access checks and cannot directly inherit the success qualifications of the old version.

[0147] In S43, batch recovery first requires that the current remaining resource gap be zero for three consecutive effective scheduling cycles. This number comes from short-term resource pressure calibration. In the example setting, the gap temporarily disappearing due to keyframe processing and network bursts lasts for a maximum of two cycles, so one more cycle is observed. This condition only allows entry into the pre-recovery check and does not directly indicate that the temporary quota can be withdrawn.

[0148] The processor reads the latest scheduling snapshot, current projected demand, existing effective budget, and resource recovery records to calculate the recipient budget after withdrawing this batch of temporary quotas and the supplier budget after recovery. Recovery for this batch will not be executed if the recipient budget is insufficient, the total budget exceeds manageable capacity, protection boundaries cannot be met, or higher protection level services arrive.

[0149] Each batch processes only one supply entity and its corresponding granting relationship. This granularity stems from the processing requirements in recovery verification that necessitate differentiation of specific control scopes. Batches are arranged in reverse order of actual action records and cannot be reordered based on resource type names. The corresponding recipient's quota is temporarily withdrawn and read back before the supplier settings are restored; actual memory usage must be able to drop normally to within the intended recovery budget.

[0150] During the trial recovery period, the original granting relationship and the pre-recovery state are retained. The corresponding quota will take effect either in the recipient's granting state or the supplier's trial recovery state, and the compensation mark will not increase the total resource amount. If the trial recovery is successful, the relationship will be officially recorded as restored; if the trial recovery fails, the changes caused by the trial recovery will be revoked according to the pre-recovery state, and the original grant amount will not be accumulated as a new grant.

[0151] After a failed recovery attempt, compensation first re-limits the supply side, verifies the current available resource quantity, and then restores the corresponding quota for the receiver within the original authorization range. If the verifiable quantity is insufficient, the old granted value is not directly copied; the incomplete recovery status is retained, and the current demand is reprocessed. New actions resulting from compensation increase the generation, saving the new execution results and recovery basis.

[0152] After each batch is completed, a new scheduling snapshot is generated, and the current remaining gaps, active services, basic support services, and supplier status are checked, and corresponding S41 verifications are performed. If any check fails, subsequent recovery is stopped. Batches that have already passed and completed are kept in the recovery status, while failed batches retain their incomplete records, and all historical states are not overwritten with the same status.

[0153] The business resource requirement statistics table is grouped by terminal model, system software version, service type, session mode, camera status, audio status, network egress, core scope, and resource type. Each sample stores the control budget, actual usage, resource limit status, and verification result for the corresponding verification window. The same window is only registered once; multiple sampled values ​​within a window cannot be treated as multiple independent verification samples.

[0154] When the CPU is subject to quota restrictions, lower actual usage cannot be considered as full demand; when the network is continuously queuing due to local rate limiting, the actual transmission rate cannot be considered as full demand; similarly, when memory allocation is rejected by the budget or cache is continuously forced to be released due to budget constraints, demand will not be reduced based on lower usage. These states are determined by the corresponding interface counts and managed manager event logs.

[0155] Sample admission requires valid measurements, successful business verification, no rollbacks or compensations within the window, and no resource limitations. Verification windows that restart after a normal recovery can form samples under the same conditions; windows that fail to recover during trial periods are not included in the statistics. Interaction latency, audio interruptions, and heartbeats are only used for admission determination and are not considered in resource requirements.

[0156] Each complete state group is updated after obtaining 30 valid windows. This number comes from the maintenance plan's repeated validation batches of each independent state. Each group meets the 30-window requirement without supplementing with samples from other states. The initial data is also calibrated according to the same state range, and the corresponding initial version continues to be used if the resource requirement table does not meet the update quantity.

[0157] For CPU and network samples, the higher demand value within the complete statistical interval of the window is used; for memory, the higher actual usage value within the window is used. The 30 samples are arranged in ascending order of resource quantity, with the first item being the lowest observed value, the average of the 15th and 16th items being the median, and the 30th item being the highest observed value. After obtaining 30 new valid windows, a new version is generated using this batch of new samples, while the old version is retained.

[0158] In the example, the 30 CPU samples consist of 10 observations at 1480ms, 10 at 1560ms, and 10 at 1620ms, with the lowest observation at 1480ms, the median at 1560ms, and the highest at 1620ms. Memory and network are processed separately using the same procedure. Forecast demand is calculated based on the larger of the highest observation, the current effective demand observation, and the protection boundary; statistics from different resources are not combined.

[0159] When the business status or interface version changes, only matching groups are used; if there are no matching samples, the corresponding initial calibration value is used. Updates to the statistics table only affect the determination of subsequent S2 requirements, do not automatically lower the hard reserve boundary, do not expand the action range in the capability table, and do not change the actual grant amount and recovery record of completed transactions.

[0160] In a complete numerical embodiment, the smart central screen terminal transitions from background content prefetching, log uploading, and cache maintenance to video call mode. The following values ​​are for demonstration purposes, calculations, and branching, and do not represent actual product test results.

[0161] In this example, all four cores are online, with a theoretical cumulative time of 4000ms. The system overhead reserve budget is 400ms, which is set by the kernel, interrupts, and unmanaged overhead calibration in this example. The manageable budget is 3600ms. The budgets for basic assurance, session support, active services, the first CPU provisioning entity, the second CPU provisioning entity, and other managed entities are 720ms, 360ms, 1320ms, 800ms, 200ms, and 200ms respectively, totaling 3600ms.

[0162] After startup, the manageable physical memory in this example is 1792 MiB, which is used as the sample startup read result. The budgets for basic security, session support, active services, first memory supply entity, second memory supply entity, other objects, system overhead, and idle protection are 430 MiB, 180 MiB, 620 MiB, 280 MiB, 64 MiB, 58 MiB, 128 MiB, and 32 MiB respectively, totaling 1792 MiB. Control budgets and actual usage are recorded separately; unused budgets are not re-granted due to temporary idleness.

[0163] In this example, the total budget for the local controlled network egress is 8 Mbps, a value derived from the example egress shaping configuration. The budgets for basic assurance, session support, active services, log upload, and other managed objects are 0.4 Mbps, 0.5 Mbps, 2.4 Mbps, 1.5 Mbps, and 3.2 Mbps, respectively, totaling 8 Mbps.

[0164] The main entity for video calls gains focus, while the camera, call audio processing, image synthesis, and network transmission entities form dependencies through actual calls. The basic audio routing has an independent control objective and falls under the basic protection resource control domain; the call audio processing entity falls under the session support resource control domain. Members that cannot be independently controlled but are jointly controlled with the basic protection service are included in the basic protection resource control domain along with the entire resource control entity, and their resource control actions are restricted according to the protection requirements corresponding to Level 4 business protection level.

[0165] The scheduling snapshot reference time is 865201.900s of the monotonic clock at this startup. The time deviations of task, CPU, memory, graphics, network, temperature, and power data are 4ms, 7ms, 11ms, 9ms, 13ms, 12ms, and 10ms, respectively, all meeting the 20ms condition determined by calibration in S13. The example temperature value is 72℃, and the power margin is 1100mW, meeting the example protection configuration described in S22; the graphics queue latency is 8ms, which is saved as a running status record.

[0166] The projected service demands for the activity are 1620ms, 760MiB, and 3.1Mbps, derived from the initial demand statistics for the corresponding video call state in this example. The current budget is 1320ms, 620MiB, and 2.4Mbps, resulting in resource gaps of 300ms, 140MiB, and 0.7Mbps, respectively. The elastic boundary of the first CPU supply entity is 500ms, the first memory supply entity is 120MiB, and the log upload is 0.6Mbps, all formed using the calibration method described in S22.

[0167] The first CPU transaction reserved 300ms, reducing the supply budget from 800ms to 500ms. The actual reduction in physical resource usage was 300ms, while the increase in available resources on the system side was 286ms, a difference of 14ms, which did not exceed the 40ms deviation threshold established by S33 calibration. Verification showed a resource release of 286ms, increasing the receiver's budget to 1606ms, leaving a 14ms gap. An additional 14ms reduction in the supplier's control budget is retained in the recovery log and is no longer considered as available supply.

[0168] The original budget for the second central processing unit (CPU) supply entity was 200ms, with a flexibility boundary of 180ms, derived from the object's maintenance calibration; the interface supported this 14ms adjustment. The CPU re-captured snapshots, calculated the gap, and reserved 14ms, reducing the supply budget to 186ms. Both sides had a verification time of 14ms, and the actual grant was 14ms, bringing the active business budget to 1620ms, resulting in a CPU gap of zero. The two grants totaled 300ms, not exceeding the remaining gap.

[0169] The first memory transaction reserves 140 MiB, reduces the first provisioning entity's budget through the managed cache interface, and releases eligible caches. The actual resident usage on the entity side decreases by 140 MiB, and the available amount on the system side increases by 128 MiB. The difference between the two is 12 MiB, which does not exceed the 32 MiB deviation threshold formed by S33 calibration. Therefore, 128 MiB is actually granted, and the active service budget increases from 620 MiB to 748 MiB, leaving a gap of 12 MiB.

[0170] The second memory supply entity has a budget of 64 MiB and a resilience boundary of 48 MiB, derived from its independent maintenance calibration. After reconciliation, 12 MiB is reserved, the control budget is reduced to 52 MiB, both sides have a verification limit of 12 MiB, and the receiver's budget increases to 760 MiB. The 12 MiB not granted in the first control change retains the supplier recovery relationship and is not treated as system idle quota.

[0171] The network transaction reserve is 0.7 Mbps. The log upload budget was reduced from 1.5 Mbps to 0.8 Mbps, ensuring the reduction did not exceed the reserve, and the budget remained above the 0.6 Mbps elasticity boundary before recovery. Both entity-side and system-side verification are 0.7 Mbps, and the active service budget was increased to 3.1 Mbps. The total effective network budget remains 8 Mbps, and the system did not allocate the same egress margin to other transactions simultaneously.

[0172] The above five transactions are executed sequentially in the following order: first transaction in the CPU, second transaction in the CPU, first transaction in memory, second transaction in memory, and network transaction. Before each transaction is executed, a new valid snapshot and version verification record are obtained. The remaining gaps of the next transaction are determined only after the result of the previous transaction is updated. The initial snapshot is not shared to complete all actions.

[0173] After each grant, feedback verification as described in S41 is performed. In this example, the local interaction response latency for the five verifications is set to 110ms, 106ms, 101ms, 99ms, and 96ms respectively, all meeting the 120ms acceptance limit for this example; the source of this limit has been explained in S41. Audio interruption in each window is 0ms, input distribution heartbeat is 210ms, system interface heartbeat is 260ms, video and local connectivity checks pass, and the supplier's task progress meets its respective deadline. The above latency is a set verification record and is not directly obtained from resource quota calculations.

[0174] The user then switched to the lower-load video call mode already configured on the terminal. The initial requirements for this mode were recorded as 1250ms, 580MiB, and 2.2Mbps, values ​​derived from an independent calibration example for this mode. After the processor updated the service status and requirements records, and the resource deficit remained zero for three consecutive valid cycles, the system checked and confirmed, according to S43, that the budget after the withdrawal of the temporary credit limit still met the requirements before attempting to restore the service.

[0175] Recovery proceeds in reverse order of the actual transactions: first network transactions, then the second memory transaction, the first memory transaction, the second CPU transaction, and finally the first CPU transaction. Memory batches are only withdrawn after the corresponding buffers on the receiving end are properly released; the upper limit cannot be reduced solely based on the budget value. Each batch also verifies whether the control changes not granted by the original supplier provide the necessary recovery capacity.

[0176] In this example, the network and two memory cycles were successfully restored. After the second batch of central processing units withdrew the 14ms temporary allowance, the active service budget changed from 1620ms to 1606ms, the supplier budget was restored to 200ms, and the example interaction response latency was 112ms, meeting the S41 service acceptance configuration.

[0177] The final CPU recovery attempt temporarily reduced the receiver budget from 1606ms to 1320ms and restored the first supplier budget from 500ms to 800ms. The pre-recovery budget check passed, but the verification window measured an interaction response latency of 128ms, exceeding the 120ms limit adopted by S41. Therefore, this batch of recovery attempts failed, while previously successful batches remained in the recovered state.

[0178] The processor adds an action generation to the failed batch, re-limiting the first supplier to 500ms. After remeasurement, this example obtains a verifiable margin of 286ms. Within the original grant relationship retention range, the receiver's budget is restored to 1606ms, the trial recovery is cancelled, and the 286ms is not accumulated again as a new grant. If the re-verification is less than 286ms, the incomplete state is retained according to S43, and the old value cannot be copied directly.

[0179] Failure windows occurring at 128ms are not included in the business resource requirement statistics table. 96ms or 112ms are only saved as business verification results for the corresponding windows. Only CPU, memory, and network requirements recorded in the corresponding windows that are not subject to resource restrictions and pass other access checks are included in the statistical sample.

[0180] In another specific embodiment, this embodiment will describe system storage, policy verification, and abnormal startup handling.

[0181] The storage system includes a task and resource state storage area, a rule storage area, and a transaction persistence area. The task and resource state storage area stores version records formed by S1 and S2; the rule storage area stores local resource protection rules and initial requirement records; and the transaction persistence area stores resource reservation records, pre-action states, execution results, and resource recovery records. If persistence fails, the corresponding underlying action is not executed.

[0182] Record updates employ a method of retaining the old version and appending the new status, saving transaction identifiers, action generations, write order, and integrity check results. During recovery, the last complete status record is verified first, followed by checking the underlying actual status. If only a pre-execution record exists without a post-execution confirmation, it is treated as pending confirmation; the absence of a successful record does not preclude the conclusion that the action did not occur.

[0183] Remote resource policies are divided into business policy payloads and verification metadata. The business policy payload includes the business type, protection level, allowed downgrade range, and effective time window; the verification metadata includes the publisher identifier, policy version, signature information, and algorithm identifier. The terminal uses the locally configured password verification component and the publisher's public key to complete the signature verification. The algorithm and public key are derived from the firmware configuration that has undergone local integrity checks. Unauthorized public keys specified by the policy itself are not accepted.

[0184] After the signature, publisher, version, and validity period checks are passed, the intersection of the remote permitted scope and the local resource protection rule permitted scope will be calculated. If the remote policy requires lowering basic protection requirements, exceeding the single action limit, or expanding underlying control capabilities, the corresponding content will be rejected. New policies relying on calendar expiration dates will not be accepted if a trusted calendar time has not yet been established. Confirmed policies will be converted to the monotonic clock expiration time within this startup, and will be re-checked after a restart.

[0185] Local resource protection rules remain unchanged during the operation of the released version. Before a planned upgrade or interface replacement, new transactions are stopped, pending clear results from ongoing actions, and the corresponding recovery is completed while the old interface remains usable; subsequently, the system and capability versions are switched. If recovery is not yet complete, the original occupancy relationship is released simply by incrementing the version number.

[0186] After an abnormal restart, the processor scans all records that have not yet been confirmed for recovery, including records with pending confirmation, pending verification, verified but not recovered, in recovery process, and failed recovery attempts. Object instances from the old startup cannot be directly used as write targets for the new startup, and old grants are not directly restored to the current valid budget. The processor reads the current object and control states and redetermines existing protection boundaries and resource ownership.

[0187] When an unplanned interface change occurs, stop submitting old actions and check if a verified compatible recovery path exists in the current version. If the correspondence between the object and the control state can be confirmed, proceed according to the current interface; if it cannot be confirmed, retain the pending maintenance state, maintain the restrictions required by the local resource protection rules, and do not write the old control state to new objects with reuse numbers.

[0188] The processor will only allow new resource reclamation transactions to be received within the corresponding control scope after all relevant in-transit actions, resource recovery records, and basic assurance status have been clearly processed. The business resource requirement statistics table is selected based on the current system and interface version; old version records are retained for tracking purposes and will not be used as unchecked new version input due to startup or upgrades.

[0189] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A system resource allocation method based on partitioned scheduling, applied to a smart mid-screen terminal, characterized in that, include: Collect running tasks and underlying resource control capabilities to generate task resource records, resource control entities, and resource control capability tables; construct session dependency graphs and session dependency sets based on runtime dependency evidence, and generate scheduling snapshots by combining resource measurement records. Based on the session dependency set and scheduling snapshot, the unique resource control domain affiliation of the resource control entity is determined, the resource boundary and resource gap are determined respectively, and resource control domain records and version verification records are generated; Based on the resource control domain records, supply resource control entities are screened, and effective resource reservation records and resource reclamation transactions are established across scheduling cycles. Before execution, resource recovery records are persisted and the version is verified. The verified resource release amount is determined according to the measurement results of the resource control entity side and the system side. The granting and updating of resource recovery records are performed within the current remaining resource gap. Verify the operational status of the activity business, basic support services, and supply resource control entities based on the resource recovery records and operation measurement records; if the verification fails, perform recovery processing and generate scheduling restriction records; if the verification passes and the recovery conditions are met, restore and verify in batches, and use the qualified resource measurement records to update the business resource demand statistics table.

2. The system resource allocation method based on partition scheduling according to claim 1, characterized in that, The generation of the task resource record, resource control entity, and resource control capability table includes: Collect the processes, threads, central processing unit control group, memory control group, graphics rendering context, audio session, network socket and device control session corresponding to the running task, and record the resource object instance identifier, parent-child relationship, current session identifier, service type, resource type and resource usage; Based on resource type, resource objects that are jointly controlled by the same control interface instance and control target and cannot have their control quantities set separately are formed into resource control entities. For the same resource type, a non-overlapping range of resource objects is used for measurement, and the parent control restrictions are checked. Based on the existence of the interface, access permissions, allowed parameter range, control granularity, status readback results, and action recovery verification results during the maintenance phase, the states of being precisely executable, degradeable, or non-executable are recorded according to the resource control entity, resource type, and resource control action. Resource control entities in the non-executable state still participate in dependency analysis, resource metering, and resource control domain attribution, but do not execute the corresponding resource control action.

3. A system resource allocation method based on partitioned scheduling according to claim 1, characterized in that, The generation of the session dependency graph and session dependency set includes: Based on the business focus and task instance records, determine the front-end business root resource control entity. Using the resource control entity as a node, establish directed edges from the dependent party to the dependent party based on inter-process calls, socket communication, shared object usage, graphics buffer transmission and audio link occupancy records, and record the evidence type, validity period and collection status. The first confirmed directed edge is marked as pending confirmation; if it exists for two consecutive valid collection cycles, it is marked as confirmed; if no dependency is found for three consecutive valid collection cycles, it is marked as invalid. The number of times the collection failed is not accumulated, and a temporary protection range is generated along the relationship between pending confirmation and confirmed. From the front-end business root resource control entity, access the dependent entities layer by layer along the confirmed directed edges, and form a session dependency set by deduplicating the accessed list; if there are still unprocessed valid outgoing edges after reaching the upper limit of traversal depth, or if the analysis of the temporary protection scope is not completed, do not generate a new resource reclamation transaction based on the corresponding session.

4. A system resource allocation method based on partitioned scheduling according to claim 3, characterized in that, The determination of the ownership of the unique resource control domain includes: The resource control entities corresponding to the basic support service list are assigned to the basic support resource control domain, the front-end business root resource control entities are assigned to the activity business resource control domain, the remaining resource control entities in the session dependency set are assigned to the session support resource control domain, and the remaining resource control entities are assigned to the reclaimable resource control domain and their reclaim eligibility is recorded. When the same resource control entity meets multiple attribution conditions, a unique attribution is determined according to the order of basic guarantee resource control domain, active business resource control domain, session support resource control domain, and reclaimable resource control domain; the business protection level of each business is determined according to local resource protection rules, where basic guarantee services are level 4, real-time audio and video are level 3, other front-end interactions are level 2, and back-end deferred tasks are level 1; when the same actual control scope involves different protection requirements, the business protection levels of each business within that actual control scope are compared, and resource control actions are restricted according to the protection requirements corresponding to the business protection level with the highest value. For resource control entities referenced by multiple sessions, the total resource quantity is measured once per entity. Incremental requirements that can be attributed are saved separately according to the operation records with session identifiers. The portion that cannot be distinguished by session is retained in the entity's unique attributed resource control domain. Each referencing session is not counted repeatedly in the total resource quantity of that entity.

5. A system resource allocation method based on partitioned scheduling according to claim 1, characterized in that, The generation of the scheduling snapshot, resource boundaries, and resource gaps includes: Resource status is collected according to a unified monotonic clock. The start and end times of the statistical window for measuring and recording the CPU and network are recorded. The actual generation time of memory, temperature and power measurements is recorded. The validity period of session dependencies and resource control capabilities is checked to see if it covers the snapshot reference time. The records required for this resource reclamation transaction are checked for time deviation, data integrity, and version before and after collection. If any check fails, the scheduling snapshot is marked as invalid and is not used to generate a new resource reclamation transaction. Record the current control budget, actual resource usage, available system resources, hard reserve boundary, and flexible operation boundary respectively. Determine the predicted demand based on the business resource demand statistics table and the current business status, calculate the resource gap, and use the graphical continuity, temperature margin, and power margin for resource control action access and operation status verification.

6. A system resource allocation method based on partitioned scheduling according to claim 1, characterized in that, The generation and use of the version verification record include: Save the current session identifier, resource object instance information, session dependency graph version, resource control domain record version, resource control capability table version, local resource protection rule version, and resource control entity member information to form a version verification record that retains the original fields; The system obtains exclusive execution rights for the corresponding control scope through the unified resource management service, compares the version verification record of the original field with the current status item by item, and checks the duration of the scheduling snapshot, the dependency protection status and the current control value. If any check fails, the action that has not yet been executed is stopped. Save the control changes that have been executed in this transaction in the order of actions. In subsequent execution phases, a new version verification record will be formed based on the current state. When an external state change occurs, cancel the actions that have not yet been executed and process the actions that have already produced control effects based on the resource recovery record.

7. A system resource allocation method based on partitioned scheduling according to claim 4, characterized in that, The selection of the supply resource control entity, and the generation of resource reservation and resource recycling transactions include: Exclude session-dependent objects, temporary protected objects, objects with valid scheduling limit records, and objects with unrecovered control states from the recyclable resource control domain that are eligible for recycling. Determine the supply ceiling based on the portion of the current control budget that exceeds the elastic operating boundary and has not yet been reserved. Within the scope of exclusive processing, the supply limit, the resource gap not yet covered by the receiver, and the existing valid reservation are checked simultaneously. The exclusive scope of the valid reservation is determined by the activation identifier, the resource control entity instance identifier, and the resource type. Resource reservation records are established by comparison and exchange. The reservation amount does not exceed the supply limit, the resource gap not yet covered by the receiver, and the single action limit. Based on the control granularity supported by the interface, generate resource control actions such as reducing the CPU time quota, reducing the managed background cache capacity limit and releasing rebuildable caches, or reducing the local controlled exit transmission budget. If there is no executable level that does not exceed the reserved amount, skip the corresponding object. After the resource control action times out, first confirm the actual execution status, and do not directly release the reserved amount that has already produced control effects.

8. A system resource allocation method based on partition scheduling according to claim 1, characterized in that: When determining the verified resource release amount, measurement records with the same statistical caliber are obtained before and after the action of the same transaction on the resource control entity side and the system side respectively. After checking for completeness, time and measurement deviation, the minimum value among the actual reduction in occupation on the entity side, the increase in available capacity on the system side and the reserved capacity is taken, and aligned downward according to the granularity of the receiving interface to determine the verified resource release amount. When granting and updating the resource recovery record, the pre-control state, target state, object instance, action generation, and reverse action of each party are saved before the action of the supplier and the receiver are executed. Within the current remaining resource gap, the receiver quota is increased and read back. The quota increase amount that has taken effect and been confirmed by the read back is recorded as the actual grant amount. The resource recovery record is updated according to the actual grant amount. Executed actions that have not generated actual grants still retain the resource recovery record. If the verification fails and the recovery process is executed, the actions already performed are processed according to the resource recovery record. When the verification is successful and the recovery waiting conditions are met, the resource requirements and protection boundaries after the withdrawal of temporary quotas are checked in batches. Trial recovery is carried out by first withdrawing the temporary quota of the corresponding recipient and then restoring the supply control settings, and the resource gap and the operating status of each party are verified. If the trial recovery fails, the trial recovery is cancelled, and only the resource measurement records that have been verified, have not been rolled back and have not been subject to resource restrictions are used to update the business resource requirement statistics table.

9. A system resource allocation system based on partitioned scheduling, installed in a smart central screen terminal, comprising a memory and a processor, characterized in that: The memory stores computer programs, as well as task resource records, resource control capability tables, session dependency graphs, session dependency sets, scheduling snapshots, resource control domain records, version verification records, resource reservation records, resource recovery records, and business resource requirement statistics tables. When the processor executes the computer program, it implements a system resource allocation method based on partition scheduling as described in any one of claims 1 to 8.

10. A system resource allocation system based on partitioned scheduling according to claim 9, characterized in that: The memory stores local resource protection rules with a version, which include a basic protection service list, resource protection boundaries, prohibited recycling objects, allowed actions, single action limit, temperature protection conditions, and power protection conditions. The processor is configured to verify the business policy payload and verification metadata of the remote resource policy, and to limit the verified business types, protection levels, allowed downgrade ranges and effective time windows to the range allowed by the local resource protection rules, and to reject content that expands the underlying resource control capabilities or reduces the protection requirements of basic security services. The processor is also configured to stop new transactions and process the recovery of existing control states before planned upgrades or interface replacements, scan unrecovered resource recovery records after abnormal restarts or unplanned interface changes, verify object instances, current control states and available recovery interfaces, retain the pending maintenance state when the recovery path cannot be confirmed, and not perform old recovery actions on new objects that reuse the same number.

Images