Method, device and equipment for operating system to manage CPU cache resources and storage medium

Abstract

The embodiment of the invention provides a method, device and equipment for managing CPU cache resources through an operating system, and a storage medium, a CPU allocates the cache resources through hardware based on CLOS IDs, each CLOS ID corresponds to one interval of the cache resources, and the method comprises the steps that when the operating system is started, a special CLOS ID is allocated to a kernel of the operating system, and the CLOS ID corresponds to the interval of the cache resources; associating a CPU (Central Processing Unit) core running the kernel with an interval of a cache resource corresponding to a special CLOS ID; when the operating system runs, a CLOS ID different from the special CLOS ID is dynamically allocated to each task; and when the cut-in task of any CPU core is different from the CLOS ID of the current task of the CPU core, associating the CPU core with the CLOS ID of the cut-in task. According to the technical scheme provided by the embodiment of the invention, the static allocation mode of the cache resources of the task is changed, the cache resources of the user state task are dynamically allocated through the kernel of the operating system, and the cache resources of the kernel state are isolated from the cache resources of the user state task, so that the key task obtains the reserved cache resources.

Description

Technical Field

[0001] This application relates to the field of operating system technology, and in particular to a method, apparatus, device and storage medium for an operating system to manage CPU cache resources. Background Technology

[0002] As the demands for real-time and deterministic response in giant intelligent robot systems (especially high-degree-of-freedom, multi-tasking "giant robots") continue to increase, operating systems face severe resource contention issues in multi-core processor environments. Among these challenges, the Last-Level Cache (LLC), a critical hardware resource shared by multiple CPU cores on a System-on-a-Chip (SoC), is highly susceptible to cache pollution due to high-priority real-time tasks sharing the cache with low-priority background tasks. This leads to decreased cache hit rates for critical tasks, increased execution latency jitter, and severely compromises system real-time performance.

[0003] Current operating systems generally employ time-slice or priority-based process scheduling strategies, but lack fine-grained control over underlying hardware cache resources. While manufacturers like Intel have introduced Cache Allocation Technology (CAT) in modern x86 processors, supporting L3 cache partitioning and isolation by CLOS (Class of Service) through MSR registers such as IA32_L3_MASK_n and IA32_PQR_ASSOC, current general-purpose operating systems like Linux do not deeply integrate this with real-time task scheduling. Typical practices include statically allocating CLOS, preventing dynamic switching based on tasks; or the kernel and user-mode threads sharing the same CLOS, causing kernel activity to interfere with the real-time task cache space.

[0004] Furthermore, existing solutions do not differentiate between kernel-mode cache usage and user-mode task cache usage. When frequent interrupts or system calls occur, kernel code can crowd out cache resources that should be reserved for critical tasks, causing unpredictable latency spikes. Therefore, there is an urgent need for a mechanism that can dynamically, finely granularly, and with low overhead coordinate scheduling and cache isolation to meet the needs of real-time scenarios such as giant robots. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method, apparatus, device and storage medium for operating system management of CPU cache resources. The technical solution of embodiments of this application is based on the cache allocation technology provided by CPU hardware, changes the static allocation method of task cache resources, and dynamically allocates cache resources of user-mode tasks through the operating system kernel, isolates kernel-mode cache resources from user-mode task cache resources, so that critical tasks can obtain reserved cache resources, and meet the needs of highly real-time scenarios such as robots.

[0006] In a first aspect, embodiments of this application provide a method for an operating system to manage CPU cache resources. The CPU allocates its cache resources based on CLOS IDs via hardware, with each CLOS ID corresponding to a range of cache resources. The method includes: when the operating system starts, allocating a dedicated CLOS ID to the kernel of the operating system and associating the CPU core running the kernel with the range of cache resources corresponding to the dedicated CLOS ID; when the operating system runs, dynamically allocating a CLOS ID different from the dedicated CLOS ID to each task; when the CLOS ID of the task switched to by any CPU core is different from the CLOS ID of the current task of that CPU core, associating the CPU core with the CLOS ID of the switched task to use the cache resource range corresponding to the CLOS ID.

[0007] Based on the cache allocation technology provided by the CPU hardware, the cache resources of user-mode tasks are dynamically allocated through the operating system kernel, changing the static allocation method of task cache resources. This isolates the kernel-mode cache resources from the user-mode task cache resources, enabling critical tasks in user-mode tasks to obtain reserved cache resources, thus meeting the needs of highly real-time scenarios such as robots.

[0008] In one possible implementation of the first aspect, it further includes: adding a CLOS ID field to the control block of each task to store the CLOS ID of the task; the dynamic allocation of a CLOS ID different from the dedicated CLOS ID for each task further includes: storing the CLOS ID of the task in the control block of each task.

[0009] Therefore, a CLOS ID field for each task is added to the control block of each task so that the CLOS ID of the task can be obtained from the control block of each task when the task is scheduled.

[0010] In one possible implementation of the first aspect, the method further includes: establishing a mapping array between the CLOS ID of a task and the task ID, and obtaining the CLOS ID of the task using the mapping array; when any CPU core switches to a task, obtaining the CLOS ID of the task using the mapping array.

[0011] As described above, the CLOS ID of each task in the operating system can be uniformly managed by using the mapping array between CLOS ID and task ID. It is also possible to obtain the CLOS ID of a task when it is scheduled.

[0012] In one possible implementation of the first aspect, it further includes: when any CPU core enters the kernel mode of the operating system due to a system call or interrupt, saving the CLOS ID of the current task of the CPU and associating the CPU core with the dedicated CLOS ID; when returning to the current task, restoring the CPU core associated with the saved CLOS ID.

[0013] Therefore, by saving the CLOS ID of the current CPU's current task in the kernel mode of the operating system during a system call or interrupt, it is convenient to restore the saved CLOS ID when the task returns.

[0014] In one possible implementation of the first aspect, each CPU core corresponds to an association register; associating any CPU core with the CLOS ID of the task to be switched on by that CPU core includes: the kernel writing the CLOS ID of the task to the association register corresponding to the CPU core.

[0015] As described above, by writing the CLOS ID of the inbound task into the associated register corresponding to the CPU core, the CPU core can use the cache resources allocated for the inbound task.

[0016] In one possible implementation of the first aspect, the step of dynamically assigning a CLOS ID different from the dedicated CLOS ID to each task includes: dynamically assigning a CLOS ID different from the dedicated CLOS ID to any task through a controlled system call, and writing the assigned CLOS ID into the CLOS ID field of the task's control block, wherein the controlled system call is for the kernel to verify that the caller has the permission to use the system call.

[0017] As described above, by dynamically allocating the CLOS ID of a task through a system call, the CLOS ID of the task can be dynamically allocated or adjusted when the task is not running. Moreover, this system call is a controlled system call, which can only be used by some programs in privileged user space, so as to protect the CLOS ID of the task from being tampered with.

[0018] In one possible implementation of the first aspect, each CLOS ID corresponds to a bitmap register; the method further includes: allocating corresponding cache resources for any CLOS ID different from the specific CLOS ID through a controlled system call, and writing the address bitmap of the cache resource range corresponding to the CLOS ID into the bitmap register corresponding to the CLOS ID, wherein the controlled system call is the kernel verifying that the caller has the right to use the system call.

[0019] As described above, the cache resource range corresponding to each CLOS ID is dynamically allocated through system calls. Moreover, this system call is a controlled system call, which can only be used by some programs in privileged user space, in order to protect the cache resource range corresponding to the CLOS ID from being tampered with.

[0020] Secondly, embodiments of this application provide an apparatus for an operating system to manage CPU cache resources. The CPU allocates its cache resources based on CLOS IDs via hardware, with each CLOS ID corresponding to a range of cache resources. The apparatus includes: a kernel allocation module, configured to allocate a dedicated CLOS ID to the kernel of the operating system when the operating system starts, and associate the CPU core running the kernel with the range of cache resources corresponding to the dedicated CLOS ID; a task allocation module, configured to dynamically allocate a CLOS ID different from the dedicated CLOS ID to each task when the operating system is running; and a resource association module, configured to associate the CPU core with the CLOS ID of the task it is switching into when the CLOS ID of the task is different from the CLOS ID of the current task of the CPU core, so as to use the range of cache resources corresponding to the CLOS ID.

[0021] Based on the cache allocation technology provided by the CPU hardware, the cache resources of user-mode tasks are dynamically allocated through the operating system kernel, changing the static allocation method of task cache resources. This isolates the kernel-mode cache resources from the user-mode task cache resources, enabling critical tasks in user-mode tasks to obtain reserved cache resources, thus meeting the needs of highly real-time scenarios such as robots.

[0022] In one possible implementation of the second aspect, a CLOSID field for the task is added to the control block of each task; the task allocation module is also used to store the CLOS ID of the task in the control block of each task.

[0023] Therefore, a CLOS ID field for each task is added to the control block of each task so that the CLOS ID of the task can be obtained from the control block of each task when the task is scheduled.

[0024] In one possible implementation of the second aspect, the task allocation module is further configured to establish a mapping array between the CLOSID of a task and the task ID, and obtain the CLOS ID of the task using the mapping array. When any CPU core switches to a task, the CLOS ID of the task is obtained using the mapping array.

[0025] As described above, the CLOS ID of each task in the operating system can be uniformly managed by using the mapping array between CLOS ID and task ID. It is also possible to obtain the CLOS ID of a task when it is scheduled.

[0026] In one possible implementation of the second aspect, the resource association module is further configured to save the CLOS ID of the current task of any CPU core when the CPU core enters the kernel mode of the operating system due to a system call or interrupt, and associate the CPU core with the dedicated CLOS ID; when returning to the current task, restore the CPU core to the saved CLOS ID.

[0027] Therefore, by saving the CLOS ID of the current CPU's current task in the kernel mode of the operating system during a system call or interrupt, it is convenient to restore the saved CLOS ID when the task returns.

[0028] In one possible implementation of the second aspect, each CPU core corresponds to an associated register; when any CPU core is associated with the CLOS ID of the task to be switched to that CPU core, the kernel writes the CLOS ID of the task to the associated register corresponding to that CPU core.

[0029] As described above, by writing the CLOS ID of the inbound task into the associated register corresponding to the CPU core, the CPU core can use the cache resources allocated for the inbound task.

[0030] In one possible implementation of the second aspect, when dynamically assigning a CLOS ID different from the dedicated CLOS ID to each task, a controlled system call is used to dynamically assign a CLOS ID different from the dedicated CLOS ID to any task, and the assigned CLOS ID is written into the CLOS ID field of the task's control block. The controlled system call is the kernel's verification caller having the permission to use the system call.

[0031] As described above, by dynamically allocating the CLOS ID of a task through a system call, the CLOS ID of the task can be dynamically allocated or adjusted when the task is not running. Moreover, this system call is a controlled system call, which can only be used by some programs in privileged user space, so as to protect the CLOS ID of the task from being tampered with.

[0032] In one possible implementation of the second aspect, each CLOS ID corresponds to a bitmap register; through a controlled system call, a corresponding cache resource is allocated for any CLOS ID that is different from the specific CLOS ID, and the address bitmap of the cache resource range corresponding to the CLOS ID is written into the bitmap register corresponding to the CLOS ID, wherein the controlled system call is the kernel verifying that the caller has the right to use the system call.

[0033] As described above, the cache resource range corresponding to each CLOS ID is dynamically allocated through system calls. Moreover, this system call is a controlled system call, which can only be used by some programs in privileged user space, in order to protect the cache resource range corresponding to the CLOS ID from being tampered with.

[0034] Thirdly, embodiments of this application provide a computing device, including,

[0035] bus;

[0036] A communication interface, which is connected to the bus;

[0037] At least one processor connected to the bus; and

[0038] At least one memory is connected to the bus and stores program instructions that, when executed by the at least one processor, cause the at least one processor to perform the method described in any embodiment of the first aspect of this application.

[0039] Fourthly, embodiments of this application provide a computer-readable storage medium having program instructions stored thereon, which, when executed by a computer, cause the computer to perform the method described in any embodiment of the first aspect. Attached Figure Description

[0040] Figure 1 This is a flowchart illustrating a method for managing CPU cache resources in an operating system according to this application.

[0041] Figure 2 This is a flowchart illustrating a second embodiment of an operating system method for managing CPU cache resources according to this application.

[0042] Figure 3 This is a schematic diagram of an embodiment of an operating system management CPU cache resource device according to this application;

[0043] Figure 4 This is a schematic diagram of the computing device of this application. Detailed Implementation

[0044] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0045] In the following description, the terms “first, second, third, etc.” or module A, module B, module C, etc. are used not only to distinguish similar objects or different embodiments, but also do not represent a specific ordering of objects. It is understood that a specific order or sequence may be interchanged where permitted so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0046] In the following description, the labels of the steps, such as S110, S120, etc., do not necessarily mean that the steps will be executed in this way. The order of the steps can be interchanged or executed simultaneously if permitted.

[0047] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0048] This application provides a method, apparatus, device, and storage medium for an operating system to manage CPU cache resources. The CPU allocates its cache resources based on CLOS IDs via hardware, with each CLOS ID corresponding to a range of cache resources. The method includes: when the operating system starts, allocating a dedicated CLOS ID to the kernel of the operating system and associating the CPU core running the kernel with the range of cache resources corresponding to the dedicated CLOS ID; when the operating system runs, dynamically allocating a CLOS ID different from the dedicated CLOS ID to each task; when the CLOS ID of the task switched to by any CPU core is different from the CLOS ID of the current task of that CPU core, associating the CPU core with the CLOS ID of the switched task to use the cache resource range corresponding to the CLOS ID.

[0049] The technical solution of this application embodiment is based on the cache allocation technology provided by CPU hardware. It dynamically allocates cache resources for user-mode tasks through the operating system kernel, isolates kernel-mode cache resources from user-mode task cache resources, and enables critical tasks to obtain reserved cache resources to meet the needs of highly real-time scenarios such as robots.

[0050] The embodiments of this application are described below with reference to the accompanying drawings.

[0051] The embodiments of this application manage the shared on-chip cache of multiple CPU cores on the SoC chip through the operating system, and are implemented based on the RDT / CAT technology of x86 processors.

[0052] RDT (Resource Director Technology) is a series of hardware features proposed by Intel to enhance the monitoring and allocation of shared resources, primarily including CAT (Cache Allocation Technology). CAT is one of the core technologies of RDT. It controls the access permissions of different applications or virtual machines to the shared last-level cache (LLC) through service levels (Class of Service, COS) and corresponding capability masks (CBMs), thereby preventing performance degradation of critical tasks due to cache preemption. The cache resources corresponding to each CLOS x are managed through the bitmap register IA32_L3_MASK_x, and each CPU core binds to the CLOS ID through the association register IA32_PQR_ASSOC.

[0053] The following is combined Figure 1 This document presents an example of an operating system method for managing CPU cache resources.

[0054] Figure 1 The flowchart of a method for managing CPU cache resources by an operating system is shown in Embodiment 1, including steps S110 to S130.

[0055] S110: When the computer's operating system starts, a special CLOS ID is assigned to the kernel of the operating system, and the CPU core running the operating system kernel is associated with the range of cache resources corresponding to the special CLOS ID.

[0056] Specifically, during system startup, the global CLOS (Class of Service) mask table is initialized through the `ttos_setup_clos` interface. Each CLOS corresponds to an `IA32_L3_MASK_n` bitmap register (where n is the CLOS ID), used to define the L3 cache bitmap accessible to the task corresponding to each CLOS ID. CLOS ID = 0 is reserved for a kernel-specific caching strategy and explicitly identified by the constant `const int kernel_clos = 0`, ensuring that kernel code, interrupt handling, and system calls always use an independent cache region, avoiding interference with user-critical tasks.

[0057] S120: During the operation of the computer's operating system, a CLOS ID, different from the dedicated CLOS ID, is dynamically assigned to each task.

[0058] In some embodiments, a CLOS ID field for each task is added to the control block of each task; when dynamically assigning a CLOS ID to each task, the CLOS ID assigned to the task is stored in the CLOS ID field of the control block of each task so that the user's CLOS ID can be obtained when the user is scheduled.

[0059] In some embodiments, when dynamically assigning a CLOS ID different from the CLOS ID of the operating system kernel to each task, a CLOS ID is dynamically assigned to each task through controlled system calls to achieve dynamic allocation of the task's CLOS ID. A new CLOS ID can be assigned to the task even when it is not running.

[0060] In some embodiments, when dynamically assigning a CLOS ID different from the dedicated CLOS ID to each task, a controlled system call is used to dynamically assign a CLOS ID different from the dedicated CLOS ID of the operating system kernel to any task, and write the assigned CLOS ID into the CLOS ID field of the task's control block. Here, "controlled" means that the kernel verifies that the caller has the permission to use the system call. Therefore, by dynamically assigning the task's CLOS ID through a system call, the task's CLOS ID can be dynamically assigned or adjusted when the task is not running. Moreover, this system call is a controlled system call, which can only be used by certain programs in privileged user space, thus protecting the task's CLOS ID from being tampered with.

[0061] In some embodiments, each CLOS ID corresponds to a bitmap register. Through a controlled system call, cache resources are allocated to any CLOS ID that differs from the operating system kernel's specific CLOS ID, and the address bitmap of the cache resource range corresponding to that CLOS ID is written into the bitmap register. The "controlled" aspect refers to the kernel verifying that the caller has permission to use the system call. Therefore, the cache resource range corresponding to each CLOS ID is dynamically allocated through a system call, and this system call is a controlled system call, usable only by certain programs in privileged user space, thus protecting the cache resource range corresponding to the CLOS ID from being tampered with.

[0062] Specifically, the operating system provides a controlled system call interface that allows privileged user-space programs to dynamically adjust cache resource allocation strategies at runtime, including:

[0063] (1) The system call to set the address mask of the CLOS cache resource range has the following process:

[0064] The `sys_set_llc_mask(clos_id, mask)` system call is provided to write the cache resource range address mask corresponding to the specified CLOS ID to the IA32_L3_MASK_n bitmap register of that CLOS ID. The parameter `clos_id` is the target CLOS ID (must be within a valid range and cannot be 0, as the CLOS 0 kernel CLOS is protected); the parameter `mask` is a 32-bit cache resource range address bitmap mask, representing the allowed cache addresses.

[0065] After the operating system kernel verifies the caller's permissions and ensures that the mask format is valid, it executes wrmsr(IA32_L3_MASK_BASE + clos_id, mask).

[0066] (2) A system call to bind a task thread to a specified CLOS ID is made to dynamically allocate CLOS IDs to the task. The process is as follows:

[0067] The system call sys_set_thread_clos(tid, clos_id) is provided to assign a CLOS ID to a specified task thread. The operating system kernel updates the CLOS ID field in the task thread control block and writes the CLOS ID of the bound task.

[0068] The next time the task thread is scheduled to any CPU core, the operating system kernel scheduler will automatically apply a new CLOS ID to the scheduled CPU core.

[0069] In some embodiments, a mapping array between task CLOS IDs and task IDs is established; the CLOS ID of the task is obtained using this mapping array, and the CLOS IDs of each task are managed. In some embodiments, when any CPU core switches to a task, the CLOS ID of that task is obtained using the mapping array. For example, pclosids is a mapping array, and the mapping relationship between CLOS IDs and task IDs is as follows:

[0070] task_clos = pclosids[task->task_id % num_pclosids];

[0071] Here, `task_clos` represents the CLOS ID of the task, supporting differentiated caching strategies for different task threads within the same process. `num_pclosids` is the number of elements in the `pclosids` array, with each element corresponding to a CLOS ID, and the `%` operator represents modulo operation.

[0072] It should be noted that the recommended mapping method is suitable for scenarios where the pclosids array is as large as the number of tasks.

[0073] In some embodiments, a corresponding cache resource range is allocated to any CLOS ID through controlled system calls. The cache range corresponding to the CLOS ID allocated for a critical task has a low first overlap with the cache range used by other tasks, and the first overlap may even be 0, i.e., they do not overlap. The cache range corresponding to the CLOS ID allocated for a non-critical task has a high second overlap with the cache range used by other tasks, and the second overlap is higher than the first overlap.

[0074] S130: When the task switched to by any CPU core is different from the CLOS ID of the current task of that CPU core, the CPU core is associated with the CLOS ID of the switched task so as to use the cache resource range corresponding to the CLOS ID.

[0075] In some embodiments, when any CPU core is associated with the CLOS ID of the task to be sliced ​​by that CPU core, the operating system kernel writes the CLOS ID of the task to the associated register of the CPU core, so that the CPU core can use the cache resources allocated for the task to be sliced.

[0076] The specific process of this step includes: when the operating system scheduler performs task switching, it compares the CLOS ID of the target task thread (the task being switched in) with the CLOS ID already bound to the current CPU core. If they are the same (including both using kernel CLOS 0), the writing to the association register IA32_PQR_ASSOC is skipped to reduce overhead; if they are different, the current CPU core is associated with the new CLOS ID by writing to the association register IA32_PQR_ASSOC, thereby applying the corresponding bitmap register IA32_L3_MASK_n to obtain the corresponding cache resource range.

[0077] In some embodiments, when any CPU core enters the kernel mode of the operating system due to a system call or interrupt, the CLOS ID of the current task of that CPU is saved, and the CPU core is associated with the cache resource range corresponding to the CLOS ID of the kernel of the operating system. When returning to the current task, the cache resource range associated with the saved CLOS ID of the CPU core is restored. Specifically, when the current CPU core enters the kernel mode due to a system call or interrupt, the CLOS ID of the current task is automatically saved and associated with the cache range of CLOS 0 indicated by kernel_clos = 0. When returning to the user-mode task thread, the CLOS ID of the current CPU core associated with the original user-mode task thread is restored, realizing complete isolation between the kernel and task cache spaces.

[0078] In summary, the first embodiment of an operating system method for managing CPU cache resources, through a hardware-software co-design, leverages the cache allocation technology provided by the CPU hardware. It dynamically allocates cache resources for user-mode tasks through the operating system kernel, changing the static allocation method of task cache resources and isolating kernel-mode cache resources from user-mode task cache resources. This ensures that critical tasks obtain reserved cache resources, fundamentally solving the real-time uncertainty problem caused by shared cache. It is particularly suitable for giant robot control systems with extremely high requirements for determinism, stability, and predictability, meeting the needs of strong real-time scenarios as next-generation real-time operating systems evolve towards hardware perception and programmable resources.

[0079] The following is combined Figure 2 This document presents a second example of an operating system method for managing CPU cache resources.

[0080] For ease of explanation, the following explanation will use an x86-64 architecture multi-core processor as an example.

[0081] Figure 2 The flowchart of a second embodiment of an operating system method for managing CPU cache resources is shown, including steps S210 to S240.

[0082] This example uses four CLOS (ID 0~3) to illustrate the process of switching from task A to task B, where task A is a kernel task.

[0083] S210: After the operating system confirms that the CPU chip supports the RDT / CAT feature, it configures the cache resource range corresponding to each CLOS ID. This includes:

[0084] (1) The operating system sets the bitmap register IA32_L3_MASK_x via a system call. Example:

[0085] IA32_L3_MASK_0 = 0x00F (Kernel uses a minimum of 4-way cache).

[0086] IA32_L3_MASK_1 = 0x0F0 (High-priority tasks use the middle 4 paths).

[0087] IA32_L3_MASK_2 = 0xF00 (Use high 4 for normal tasks).

[0088] IA32_L3_MASK_3 = 0xFFF (Debug task full cache access).

[0089] Among them, debugging tasks are not critical tasks and can access the operating system's kernel cache resources.

[0090] (2) The operating system defines the CLOS mapping array of tasks through system calls to determine the CLOS ID of each task. For example: pclosids is a CLOS mapping array.

[0091] pclosids = {1, 1, 2, 2}, num_pclosids = 4,

[0092] Task A (task_id=0) → The CLOS ID of Task A is task_clos = pclosids[0 % 4] = 1.

[0093] Task B (task_id=2) → The CLOS ID of Task B is task_clos = pclosids[2 % 4] = 2.

[0094] It should be noted that there are only 4 tasks here. If more tasks are added, the number of elements in pclosids should also be increased.

[0095] S220: When the scheduler switches the current CPU core from kernel task A to task B, it associates the current CPU core with the CLOS ID of task B. This includes:

[0096] (1) The current CPU core's CLOS is detected to be 1, while the target task B's CLOS is 2, which are different;

[0097] (2) Execute wrmsr(IA32_PQR_ASSOC, (uint64_t)2 << 32) to bind the current CPU core to CLOS 2 through the associated register IA32_PQR_ASSOC.

[0098] (3) Subsequent memory access for task B will be limited to the cache range defined by IA32_L3_MASK_2 = 0xF00.

[0099] S230: When task B initiates a system call and enters the kernel, the operating system kernel saves task B's CLOSID and associates the current CPU core with the kernel CLOSID. This includes:

[0100] The kernel saves the current CLOS 2 and switches to kernel_clos = 0, writing IA32_PQR_ASSOC to 0. After that, the kernel code executes using a dedicated, independent cache area.

[0101] S240: When a system call returns to task B, the CLOS ID of task B is restored on the current CPU core. This includes:

[0102] When the system call returns to task B, wrmsr(IA32_PQR_ASSOC, (uint64_t)2 << 32) is executed, restoring CLOS 2 of task B on the current CPU core.

[0103] In summary, in Embodiment 2 of the method for managing CPU cache resources by an operating system, the real-time degradation problem caused by cache resource contention in a multi-tasking environment is solved through a dynamic cache isolation and process scheduling coordination mechanism of the operating system kernel. It achieves cache isolation and separation between kernel-mode and user-mode threads, ensuring that kernel activities do not encroach on the cache quota of critical tasks. It supports dynamic allocation of task-level CLOS, allowing different threads within the same process to use different caching strategies. It automatically and efficiently switches CLOS IDs during task switching, writing to the associated register MSR only when necessary, reducing context switching overhead. Leveraging CPU hardware characteristics, it implements deterministic and configurable LLC cache capacity limits, improving the cache hit rate and execution stability of high-priority tasks. This embodiment deeply couples hardware cache partitioning capabilities with the operating system scheduler, realizing an integrated real-time guarantee mechanism of "scheduling as resource allocation".

[0104] The following is combined Figure 3 An embodiment of an operating system management CPU cache resource device is described.

[0105] An embodiment of an operating system management CPU cache resource apparatus performs an embodiment of an operating system management CPU cache resource method described in Embodiment 1, which embodies all its advantages.

[0106] Figure 3 The structure of an embodiment of an operating system management CPU cache resource device is shown, including: a kernel allocation module 310, a task allocation module 320, and a resource association module 330.

[0107] The kernel allocation module 310 is used to allocate a special CLOS ID to the kernel of the operating system when the computer's operating system starts, and associate the CPU core running the operating system kernel with the cache resource range corresponding to the special CLOS ID. For its working principle and advantages, please refer to step S110 of Embodiment 1 of a method for managing CPU cache resources in an operating system.

[0108] The task allocation module 320 is used to dynamically allocate a CLOS ID, different from a dedicated CLOS ID, to each task during the operation of the computer's operating system. For its working principle and advantages, please refer to step S120 of Embodiment 1 of a method for managing CPU cache resources in an operating system.

[0109] The resource association module 330 is used to associate a CPU core with the CLOS ID of the task it is switching into when the CLOS ID of the task is different from that of the current task of the CPU core, so as to use the cache resource range corresponding to the CLOS ID. For its working principle and advantages, please refer to step S130 of Embodiment 1 of a method for managing CPU cache resources in an operating system.

[0110] This application also provides a computing device, which will be described below in conjunction with... Figure 4 Detailed introduction.

[0111] The computing device 400 includes a processor 410, a memory 420, a communication interface 430, and a bus 440.

[0112] It should be understood that the communication interface 430 in the computing device 400 shown in the figure can be used to communicate with other devices.

[0113] The processor 410 can be connected to the memory 420. The memory 420 can be used to store the program code and data. Therefore, the memory 420 can be a storage unit inside the processor 410, an external storage unit independent of the processor 410, or a component that includes both the storage unit inside the processor 410 and the external storage unit independent of the processor 410.

[0114] Optionally, the computing device 400 may also include a bus 440. The memory 420 and communication interface 430 can be connected to the processor 410 via the bus 440. The bus 440 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus 440 can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one line is used in this figure, but this does not mean that there is only one bus or one type of bus.

[0115] It should be understood that in the embodiments of this application, the processor 410 may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. Alternatively, the processor 410 may employ one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0116] The memory 420 may include read-only memory and random access memory, and provides instructions and data to the processor 410. A portion of the processor 410 may also include non-volatile random access memory. For example, the processor 410 may also store device type information.

[0117] When the computing device 400 is running, the processor 410 executes computer execution instructions stored in the memory 420 to perform the operation steps of each method embodiment.

[0118] It should be understood that the computing device 400 according to the embodiments of this application can correspond to the corresponding subject in executing the methods according to the various embodiments of this application, and the above and other operations and / or functions of each module in the computing device 400 are respectively for implementing the corresponding processes of the methods of this embodiment. For the sake of brevity, they will not be described in detail here.

[0119] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0120] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0121] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0122] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0123] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0124] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0125] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is used to perform the operation steps of the various method embodiments.

[0126] The computer storage medium in this application embodiment can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0127] Computer-readable signal media may include data signals transmitted in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which can send, transmit, or transmit programs for use by or in connection with an instruction execution system, apparatus, or device.

[0128] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0129] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0130] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, all of which fall within the scope of protection of this application.

Claims

1. A method for managing CPU cache resources in an operating system, characterized in that, The CPU allocates its cache resources based on CLOS ID via hardware, with each CLOS ID corresponding to a range of cache resources. The method includes: When the operating system starts, a special CLOS ID is assigned to the kernel of the operating system, and the CPU core running the kernel is associated with the range of cache resources corresponding to the special CLOS ID; During the operation of the operating system, a CLOS ID different from the dedicated CLOS ID is dynamically assigned to each task; When the CLOS ID of the task switched to by any CPU core is different from that of the current task of that CPU core, the CPU core is associated with the CLOS ID of the switched task so that the cache resource range corresponding to the CLOS ID can be used.

2. The method according to claim 1, characterized in that, Also includes: Add a CLOS ID field to the control block of each task to store the CLOS ID of that task.

3. The method according to claim 1, characterized in that, Also includes: Establish an array mapping between task CLOS IDs and task IDs; When any CPU core switches to a task, the CLOS ID of that task is obtained using the mapping array.

4. The method according to claim 1, characterized in that, Also includes: When any CPU core enters the kernel mode of the operating system due to a system call or interrupt, the CLOS ID of the current task of that CPU is saved, and the CPU core is associated with the cache resource range corresponding to the specific CLOS ID; When returning to the current task, restore the CPU core associated with the cache resource range corresponding to the saved CLOS ID.

5. The method according to claim 1, characterized in that, Each CPU core corresponds to one associated register; Associating any CPU core with the CLOS ID of the task to be sliced ​​by that CPU core includes: the kernel writing the CLOS ID of the task to the associated register corresponding to the CPU core.

6. The method according to claim 2, characterized in that, The dynamic allocation of a CLOS ID, which is different from the dedicated CLOSID, to each task includes: Through controlled system calls, a CLOS ID different from the dedicated CLOS ID is dynamically assigned to any task, and the assigned CLOS ID is written into the CLOS ID field of the task's control block. The "controlled" aspect refers to the kernel verifying that the caller has the right to use the system call.

7. The method according to claim 1, characterized in that, Each CLOS ID corresponds to a bitmap register; the method further includes: Through a controlled system call, a corresponding cache resource is allocated for any CLOS ID that is different from the specific CLOS ID, and the address bitmap of the cache resource range corresponding to the CLOS ID is written into the bitmap register corresponding to the CLOS ID. The "controlled" part means that the kernel verifies that the caller has the right to use the system call.

8. An apparatus for managing CPU cache resources in an operating system, characterized in that, The CPU allocates its cache resources based on CLOS ID via hardware, with each CLOS ID corresponding to a range of cache resources. The device includes: The kernel allocation module is used to allocate a special CLOSID to the kernel of the operating system when the operating system starts, and associate the CPU core running the kernel with the range of cache resources corresponding to the special CLOSID; The task allocation module is used to dynamically allocate a CLOS ID, which is different from the dedicated CLOS ID, to each task when the operating system is running. The resource association module is used to associate a CPU core with the CLOS ID of the task it is assigned to when the CLOS ID of the task is different from that of the current task of the CPU core, so as to use the cache resource range corresponding to the CLOS ID.

9. A computing device, characterized in that, include, bus; A communication interface, which is connected to the bus; At least one processor is connected to the bus; as well as At least one memory connected to the bus and storing program instructions that, when executed by the at least one processor, cause the at least one processor to perform the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores program instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 7.

Images