Linux-based preference hint scheduling method and system

Abstract

This invention discloses a Linux-based preference-based scheduling method and system. The method includes: extending the Linux kernel's data structures by adding a member variable to the task structure to record task preference CPU information, and adding a member variable to the CPU run queue structure to count the total task load of the current CPU in the run queue based on preference CPU information; during task scheduling, when a task sets a preference CPU set, the scheduler prioritizes selecting a CPU with a lighter load within that set; if no CPU meets the conditions in the set, the scheduling strategy degenerates to the default; during load balancing, tasks without set CPU preferences are migrated first; the system is used to execute this method. This invention, by introducing a non-mandatory CPU preference hint mechanism, enables the scheduler to perceive task execution preferences and dynamically adjust scheduling decisions when the load changes, thereby improving the overall system resource utilization and scheduling flexibility.

Description

Technical Field

[0001] This invention relates to the field of computer operating system technology, and specifically to a preference suggestion scheduling method and system based on Linux. Background Technology

[0002] With the rapid development of cloud computing and big data technologies, multi-core servers using Non-Unified Memory Access (NUMA) architecture have become mainstream. To reduce cross-node access latency and improve I / O performance, existing technologies generally adopt a CPU "core binding" strategy, which forces and fixes specific processes (such as network or storage service processes) to run on the same CPU core located on the same NUMA node as the relevant hardware device.

[0003] However, this static "core-binding" strategy has significant drawbacks: Poor flexibility and low resource utilization: Binding is mandatory and exclusive. When the CPU resources of the bound node are scarce or saturated, tasks cannot utilize the idle CPU resources on other NUMA nodes, resulting in uneven overall system load, with some CPUs overloaded while others are idle, leading to reduced resource utilization.

[0004] High operational complexity and difficulty in automation: Core binding operations typically rely on manual intervention by administrators, requiring in-depth understanding of hardware topology and business characteristics. In complex and ever-changing business environments, developing and maintaining optimal core binding solutions requires extremely high levels of expertise, and dynamic adjustments and automated operations are difficult to achieve, resulting in high costs.

[0005] The strategy is rigid and inflexible: it is a hard constraint of "either / or" and cannot express a flexible tendency of "prioritizing but not forcing". It cannot adapt to dynamic changes in load, sacrificing the overall resilience and reliability of the system while pursuing local performance optimization.

[0006] Regarding scheduling optimization, existing technologies have other research directions. For example, some patents (such as CN202311287739.0) improve real-time performance by refining task scoring mechanisms; others (such as CN202410517367.4) automatically configure scheduling strategies using process names; and still others (such as CN202411803520.6) dynamically optimize scheduling parameters using machine learning models. These solutions focus on scheduling priority, automated strategy configuration, or parameter tuning, respectively, but none of them solve the fundamental problem of uneven resource utilization and lack of scheduling flexibility caused by the inherent static and forced binding of the aforementioned "core binding" strategy.

[0007] Therefore, there is an urgent need in this field for a new scheduling mechanism that can guide tasks to run preferentially on CPUs with better performance (such as NUMA nodes close to the hardware they access), and allow tasks to intelligently and automatically migrate to other available CPUs when these preferred CPUs are in short supply. This will ensure the performance of critical business operations while achieving dynamic balance and efficient utilization of global system resources and reducing operational complexity. Summary of the Invention

[0008] The technical problem to be solved by this invention is to provide a Linux-based preference-based scheduling method and system that addresses the aforementioned problems in the prior art. By intelligently sensing task CPU preferences and dynamically adjusting scheduling decisions when preference CPU load changes, the system can improve overall resource utilization and scheduling flexibility while maintaining local performance advantages.

[0009] To solve the above-mentioned technical problems, the technical solution adopted by the method of the present invention includes the following steps: S1 extends the data structures of the Linux kernel by adding a member variable to the task structure to record task preference CPU information, and adding a member variable to the CPU run queue structure to count the total task load of the CPU in the CPU run queue, which includes the current CPU's preference CPU information. S2 provides system call interfaces and kernel-mode interfaces for setting the preferred CPU set for a specified task; S3, when the scheduler performs task enqueueing and dequeueing operations, dynamically update the total load of preferred CPUs in the CPU run queue structure according to whether the task has set a preferred CPU and whether the current CPU belongs to its preferred set. S4. When the scheduler selects a CPU to run a task, if the task has set a preferred CPU, the available CPU with the lightest load is selected from its preferred CPU set first; if the preferred CPUs are all unavailable or too heavily loaded, the task is selected from non-preferred CPUs to run. S5 prioritizes migrating tasks that do not have a preferred CPU when performing load balancing migration tasks; for tasks with a preferred CPU, prioritize migrating tasks whose target CPU is within their preferred set; only when the total load of the preferred CPU is saturated will tasks with a preferred CPU be migrated to non-preferred CPUs.

[0010] As a further improvement to the method of this invention, step S1 specifically includes: Add the nr_cpus_preferred and cpus_preferred members to the struct task_struct structure to record the number of preferred CPUs and the set of CPU masks, respectively. Add the preferred_load and preferred_tasks members to the struct rq structure to record the preferred total CPU load and number of tasks in the current CPU run queue, respectively.

[0011] As a further improvement to the method of this invention, step S1 further includes initializing nr_cpus_preferred to 0 and cpus_preferred to an empty mask during task initialization.

[0012] As a further improvement to the method of this invention, the system call interface in step S2 is sched_setpreferred, which receives the process identifier PID and a string representing the CPU set as parameters, and includes the following steps: S21, copy the CPU set string passed from user space and parse it into the kernel's cpumask type; S22, find the corresponding task structure based on the PID; S23, perform permission verification, and only allow the task itself or a process with CAP_SYS_NICE permission to modify it; S24, assign the parsed CPU mask to the cpus_preferred member of the task structure, and update its nr_cpus_preferred member.

[0013] As a further improvement to the method of this invention, step S3 specifically includes: When a task is enqueued into the run queue of a CPU, if the nr_cpus_preferred member value of the task is greater than 0 and the current CPU number is within the cpus_preferred member value mask, then the load weight of the task is increased in the preferred_load member of the CPU's run queue, and the count value of the preferred_tasks member is incremented by 1. When a task is dequeued from the run queue of a CPU, if the nr_cpus_preferred member value of the task is greater than 0 and the current CPU number is within the cpus_preferred member value mask, then the preferred_load member value of the CPU's run queue is reduced by the load weight of the task, and the preferred_tasks member value count is decremented by 1.

[0014] As a further improvement to the method of this invention, step S4 specifically includes: S41, Determine whether the nr_cpus_preferred member value of the task to be scheduled is greater than 0; S42, if so, iterate through all online CPUs in its cpus_preferred member value mask; S43, During the traversal, compare and record the CPU with the smallest preferred_load member value as the candidate CPU; S44. If a candidate CPU is found and the number of currently running tasks on the candidate CPU does not exceed its theoretical processing capacity, then the candidate CPU is selected as the running CPU; otherwise, the default CPU selection strategy is invoked.

[0015] As a further improvement to the method of this invention, step S5 specifically includes: S51, sequentially traverse the tasks on the source CPU run queue, and check whether they need to be migrated. S52, determine whether the currently traversed task has set a CPU preference; if not, execute the default load balancing logic; if it has, execute step S53. S53, determine whether the target CPU belongs to the preferred CPU set of the task. If it does not belong, proceed to step S54; if it does belong, add the task to the list of tasks to be migrated and proceed to step S55. S54, Determine whether the total load of the preferred CPU for the task has reached the load saturation state. If it is saturated, add the task to the list of tasks to be migrated and execute step S55 to allow the task to migrate across the boundary to the non-preferred CPU. If it is not saturated, return to step S51 and continue to traverse other tasks. S55 migrates the task to the target CPU.

[0016] The present invention also provides a Linux-based preference suggestion scheduling system, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the Linux-based preference suggestion scheduling method described above.

[0017] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the Linux-based preference suggestion scheduling method described above.

[0018] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the Linux-based preference suggestion scheduling method described above.

[0019] Compared with the prior art, the advantages of the present invention are as follows: This invention fundamentally solves the rigidity problem of traditional "core-binding" strategies by introducing a "flexible binding" mechanism. It allows tasks to declare their preferred CPUs (such as NUMA nodes close to specific hardware), enabling the scheduler to prioritize these preferences for optimal performance when resources are plentiful. When the preferred CPU is overloaded, the scheduler can automatically and intelligently migrate tasks to other idle CPUs, thus ensuring the performance of critical business applications while achieving dynamic balancing and efficient utilization of global system resources. This method not only significantly improves the overall resource utilization and system resilience under NUMA architecture but also greatly simplifies operation and maintenance, providing key technical support for the automated and intelligent scheduling of high-performance computing. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating an embodiment of the present invention.

[0021] Figure 2 This is a schematic diagram illustrating the execution flow of the CPU core selection strategy according to an embodiment of the present invention. Detailed Implementation

[0022] The present invention will be further described below with reference to the accompanying drawings and specific preferred embodiments, but this does not limit the scope of protection of the present invention.

[0023] The technical solution adopted in this embodiment is as follows: Figure 1 , Figure 2 As shown, it includes the following steps: S1 extends the data structures of the Linux kernel by adding a member variable to the task structure to record task preference CPU information, and adding a member variable to the CPU run queue structure to count the total task load of the CPU in the CPU run queue, which includes the current CPU's preference CPU information. S2 provides system call interfaces and kernel-mode interfaces for setting the preferred CPU set for a specified task; S3, when the scheduler performs task enqueueing and dequeueing operations, dynamically update the total load of preferred CPUs in the CPU run queue structure according to whether the task has set a preferred CPU and whether the current CPU belongs to its preferred set. S4. When the scheduler selects a CPU to run a task, if the task has set a preferred CPU, the available CPU with the lightest load is selected from its preferred CPU set first; if the preferred CPUs are all unavailable or too heavily loaded, the task is selected from non-preferred CPUs to run. S5 prioritizes migrating tasks that do not have a preferred CPU when performing load balancing migration tasks; for tasks with a preferred CPU, prioritize migrating tasks whose target CPU is within their preferred set; only when the total load of the preferred CPU is saturated will tasks with a preferred CPU be migrated to their non-preferred CPU.

[0024] The technical solution of this embodiment achieves the following advantages: 1. A balance between performance priority and system flexibility is achieved during the CPU core selection process: Performance Priority: When the system load is light, the scheduler strictly follows the CPU preference of the task, ensuring that latency-sensitive tasks such as network and storage always run on the optimal CPU (such as the same NUMA node), maximizing the use of hardware locality and achieving performance gains comparable to traditional hard-core binding.

[0025] Elastic migration: When preferred CPU resources are scarce or saturated, the scheduling policy can automatically relax constraints, allowing tasks to be scheduled to run on other non-preferred CPUs. This avoids the task starvation or local node overload problems that may occur under the traditional core-binding strategy, ensuring the overall throughput and responsiveness of the system under high load.

[0026] 2. Improve the resource utilization of multi-core systems Through a dynamic load awareness and migration mechanism, this method effectively breaks down the resource barriers caused by traditional core binding. It intelligently diverts tasks that are stuck on busy nodes due to binding strategies to idle CPUs on other nodes, thereby eliminating the waste of resources caused by "some CPUs being overloaded and others being idle," achieving load balancing across NUMA nodes, and improving the overall utilization efficiency of hardware resources.

[0027] 3. Significantly reduce operation and maintenance complexity and costs Operations personnel or applications can simply declare task "preferences" through a straightforward interface, eliminating the need for complex, nuanced, and static "core binding" operations. This reduces reliance on operations personnel's hardware topology and professional tuning skills. Because the system has automatic load balancing capabilities, there's no need to worry about resource bottlenecks caused by improper core binding settings, making the operation and management of large-scale clusters simpler and more reliable, laying the foundation for automated operations and maintenance.

[0028] In a specific application example, step S1 specifically includes: Add the nr_cpus_preferred and cpus_preferred members to the struct task_struct structure to record the number of preferred CPUs and the set of CPU masks, respectively. Add the preferred_load and preferred_tasks members to the struct rq structure to record the preferred total CPU load and number of tasks in the current CPU run queue, respectively.

[0029] Specifically, the following members are added to the `struct task_struct` in `include / linux / sched.h`: `int nr_cpus_preferred`: records the number of preferred CPUs set for the task; a value of 0 indicates that the task has no preferred CPUs set; `cpumask_t cpus_preferred`: records the set of CPU masks for the task's preferred CPUs. `cpumask_t` is a type in the kernel used to represent a set of CPUs, which is essentially a bitmap used for scheduling, CPU binding, and migration scenarios. The following members were added to the struct rq in kernel / sched / sched.h: unsigned long preferred_load is used to count the load of tasks with the preferred CPU flag; unsigned int preferred_tasks is used to count the number of tasks with the preferred CPU flag. In the task initialization function init_task(), the following initialization is performed: nr_cpus_preferred is set to 0, indicating that the task does not use preference hint scheduling by default; cpus_preferred is set to CPU_MASK_NONE, indicating that the task does not have a preferred CPU mask set by default. In the Linux kernel, CPU_MASK_NONE is a macro used to represent an empty CPU mask.

[0030] In a specific application example, the system call interface mentioned in step S2 is sched_setpreferred, which receives the process identifier (PID) and a string representing the CPU set as parameters, including the following steps: S21, copy the CPU set string passed from user space and parse it into the kernel's cpumask type; S22, find the corresponding task structure based on the PID; S23, perform permission verification, and only allow the task itself or a process with CAP_SYS_NICE permission to modify it; S24, assign the parsed CPU mask to the cpus_preferred member of the task structure, and update its nr_cpus_preferred member.

[0031] Specifically, the definition of the new system call is as follows: SYSCALL_DEFINE2(sched_setpreferred, pid_t, pid, const char __user *, cpu_mask). This system call function is named sched_setpreferred and contains two parameters: pid_t pid, which specifies the PID of the target process; and const char __user *cpu_mask, which represents the CPU set string passed from user space, specifying the process's preferred CPU set.

[0032] The implementation process of this system call is as follows: Step S21 includes: Local variable definition: Define variable char kbuf

[32] to copy CPU set string from user space, define variable struct cpumask newmask to store the parsed CPU mask, and define variable struct task_struct*task to store target task pointer.

[0033] Copying user-space data to kernel space: The function `copy_from_user(kbuf, cpu_mask, sizeof(kbuf) - 1)` copies the CPU set string passed in by the user to the kernel buffer `kbuf`. `copy_from_user()` is a function implemented in the Linux kernel that copies data from user space to kernel space.

[0034] Parsing the CPU mask string: The function `cpumask_parse(kbuf, &newmask)` parses the CPU set from a string into a `cpumask_t` type mask. `cpumask_parse()` is a Linux kernel function used to parse a CPU mask from a string into a `cpumask_t` structure.

[0035] Step S22 includes: To obtain the target task structure, call `task = pid_task(find_get_pid(pid), PIDTYPE_PID)` to get a pointer to the task structure corresponding to the specified PID. Here, `find_get_pid()` is a kernel-implemented function that looks up the corresponding `struct pid` object based on a numeric PID, and `pid_task()` is a kernel-implemented function that retrieves the corresponding task descriptor from the `struct pid` object. `PIDTYPE_PID` indicates searching by ordinary process PID. Step S23 includes: Permission check: Only the task itself or a process with CAP_SYS_NICE privileges is allowed to modify the preferred CPU settings of other tasks. If task is not equal to current (i.e., not the task itself) and does not have CAP_SYS_NICE privileges (i.e., !capable(CAP_SYS_NICE)), an error is returned and the process exits.

[0036] Step S24 includes: To set the preferred CPU mask for a task, call the function `cpumask_copy(&task->cpus_preferred,&newmask)`, which assigns the parsed CPU mask to the `cpus_preferred` member of the task structure. `cpumask_copy()` is a kernel-implemented function for copying the CPU bitmap.

[0037] Update the preferred CPU count for a task: Call `task->nr_cpus_preferred = cpumask_weight(&newmask)` to update the preferred CPU count based on the number of bits set in the mask. Here, `cpumask_weight()` is a kernel implementation used to count the number of CPUs whose bits are set in `cpumask`.

[0038] In a specific application example, step S3 specifically includes: When a task is enqueued into the run queue of a CPU, if the nr_cpus_preferred member value of the task is greater than 0 and the current CPU number is within the cpus_preferred member value mask, then the load weight of the task is increased in the preferred_load member of the CPU's run queue, and the count value of the preferred_tasks member is incremented by 1. When a task is dequeued from the run queue of a CPU, if the nr_cpus_preferred member value of the task is greater than 0 and the current CPU number is within the cpus_preferred member value mask, then the preferred_load member value of the CPU's run queue is reduced by the load weight of the task, and the preferred_tasks member value count is decremented by 1.

[0039] Specifically, in the Linux kernel, the function for enqueuing tasks is `enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)`. Internally, the following logic needs to be added: First, it checks if `p->nr_cpus_preferred` is 0 to determine if the task has a preferred CPU. If `p->nr_cpus_preferred` is not 0, it further calls `cpumask_test_cpu(cpu_of(rq), &p->cpus_preferred)` to determine if the current CPU belongs to the task's preferred CPU set. If the result is true, the following operations are performed: `rq->preferred_load += p->se.load.weight` to increase the preferred load value in the current CPU run queue; simultaneously, `rq->preferred_tasks++` increments the number of preferred tasks in the current CPU run queue.

[0040] In the Linux kernel, the function for dequeuing tasks is `dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags)`. Internally, the following logic needs to be added: First, it checks if `p->nr_cpus_preferred` is 0 to determine if the task has a preferred CPU. If `p->nr_cpus_preferred` is not 0, it further calls `cpumask_test_cpu(cpu_of(rq),&p->cpus_preferred)` to determine if the current CPU belongs to the task's preferred CPU set. If the result is true, the following operations are performed: `rq->preferred_load -= p->se.load.weight` to reduce the preferred load value in the current CPU's run queue; simultaneously, `rq->preferred_tasks` decrements the number of preferred tasks in the current CPU's run queue.

[0041] In a specific application example, step S4 specifically includes: S41, Determine whether the nr_cpus_preferred member value of the task to be scheduled is greater than 0; S42, if so, iterate through all online CPUs in its cpus_preferred member value mask; S43, During the traversal, compare and record the CPU with the smallest preferred_load member value as the candidate CPU; S44. If a candidate CPU is found and the number of currently running tasks on the candidate CPU does not exceed its theoretical processing capacity, then the candidate CPU is selected as the running CPU; otherwise, the default CPU selection strategy is invoked.

[0042] Specifically, step S41 includes: Local variable definitions: A structure pointer `struct rq *rq` is defined to store the CPU's run queue; an integer variable `int cpu` is defined to iterate through the preferred CPU set for each task; an integer variable `int best_cpu` is defined to record the optimal scheduling target CPU; and an unsigned long integer variable `unsigned long min_load` is defined to record the CPU load value. `best_cpu` is initialized to -1, and `min_load` is initialized to `ULONG_MAX`, where `ULONG_MAX` is a constant macro representing the maximum value that an `unsigned long` type can represent.

[0043] To determine if a task has a preferred CPU: First, check if the task's nr_cpus_preferred value is greater than 0. If the value is 0, it indicates that the task has not set a preferred CPU, and the default CPU core selection logic should be followed; if the value is greater than 0, proceed to step S42 to perform the corresponding operation.

[0044] Step S42 includes: Traversing the task's preferred CPU set: Use `for_each_cpu(cpu,&p->cpus_preferred)` to traverse the task's preferred CPU set, extracting candidate CPUs one by one. Its `for_each_cpu()` is a CPU traversal macro implemented in the Linux kernel, used to traverse all CPUs in a `cpumask` that are set.

[0045] Step S43 includes: Determine CPU availability: Use the `cpu_online(cpu)` function to check if the current CPU is online. If it is offline, jump to step S42 and continue iterating to the next CPU. `cpu_online()` is a CPU status check macro implemented in the Linux kernel, used to determine if a specified CPU is currently online.

[0046] To obtain the CPU's run queue, call `rq = cpu_rq(cpu)` to get the run queue structure corresponding to that CPU. `cpu_rq()` is a function implemented in the Linux kernel used to obtain a pointer to the run queue structure corresponding to a specified CPU.

[0047] Calculate and select the preferred CPU with the lightest load: Determine whether the preferred load rq->preferred_load of the current CPU is lower than the currently recorded minimum load min_load. If the condition is true, update the optimal target CPU to the current CPU: best_cpu = cpu, and simultaneously update the minimum load value to: min_load = rq->preferred_load.

[0048] Repeat the traversal until completion: Return to repeat step S42 until the preferred CPU set traversal is complete.

[0049] Step S44 includes: The system determines whether the preferred CPU is saturated and decides on the scheduling target: If the preferred CPU's run queue is not saturated (i.e., rq->nr_running is less than rq->cpu_capacity_orig), then the best_cpu is selected as the target CPU; if it is saturated, the system uses Linux's general CPU core selection logic to select another suitable CPU as the scheduling target. Here, rq->cpu_capacity_orig represents the CPU's original processing capacity, i.e., the theoretical number of tasks the CPU can run, and rq->nr_running represents the number of tasks currently running or ready in the CPU's run queue.

[0050] In a specific application example, step S5 includes: S51, sequentially traverse the tasks on the source CPU run queue, and check whether they need to be migrated. S52, determine whether the currently traversed task has set a CPU preference; if not, execute the default load balancing logic; if it has, execute step S53. S53, determine whether the target CPU belongs to the preferred CPU set of the task. If it does not belong, proceed to step S54; if it does belong, add the task to the list of tasks to be migrated and proceed to step S55. S54, Determine whether the total load of the preferred CPU for the task has reached the load saturation state. If it is saturated, add the task to the list of tasks to be migrated and execute step S55 to allow the task to migrate across the boundary to the non-preferred CPU. If it is not saturated, return to step S51 and continue to traverse other tasks. S55 migrates the task to the target CPU.

[0051] Specifically, step S51 includes: Local variable definition: Define a structure pointer `struct task_struct *p` to represent the task being considered for migration; Traverse the task queue on the source CPU: By calling `list_for_each_entry(p,&busiest->cfs_tasks...)`, all tasks on the source run queue `busiest` are traversed. Tasks are sequentially retrieved from the source run queue and stored in the local variable `p`, while simultaneously checking if they need to be migrated. Here, `list_for_each_entry()` is a macro implemented in the Linux kernel for traversing each element in the linked list, and `busiest` is the queue found by the `load_balance()` function that requires task migration.

[0052] Step S52 includes: To determine if a task has a preferred CPU setting: Before determining whether task p needs to be migrated, first check if the value of p->nr_cpus_preferred is greater than 0 to determine if the task has a preferred CPU setting. If the value is 0, it indicates that the task has not a preferred CPU setting, and the default load balancing logic should be executed; if the value is greater than 0, the migration judgment process for tasks with preferred CPUs needs to be entered.

[0053] Step S53 includes: When task p has a preferred CPU set, the function `cpumask_test_cpu(cpu_of(dst_rq),&p->cpus_preferred)` is called to determine whether the target CPU belongs to the preferred CPU set. If the target CPU is not in this preferred CPU set, step S54 is executed to determine if the task is out of bounds; otherwise, task p is added to the list of tasks to be migrated, and the process jumps to step S55. Here, `cpumask_test_cpu()` is a Linux kernel function used to determine whether a CPU is set in a given `cpumask`, `cpu_of()` is a Linux kernel function that obtains the corresponding CPU number through a run queue pointer, and `dst_rq` is the run queue of the target CPU for the task to be migrated, as represented in the `load_balance()` function.

[0054] Step S54 includes: Out-of-bounds migration control: Determine if the CPU load preferred by task p has reached saturation (i.e., rq->preferred_load >= rq->cpu_capacity_orig). If saturated, add task p to the list of tasks to be migrated and execute step S55 to allow the task to migrate across the boundary to other CPUs, thereby preventing overall system load imbalance or task starvation; if not saturated, return to step S51 and continue traversing other tasks. rq is obtained through task_rq(p).

[0055] Step S55 includes: Task migration execution: When the target task p meets the migration conditions (i.e., the target CPU belongs to its preferred CPU set, or the target CPU is saturated and allows out-of-bounds migration), the task migration operation is performed to migrate the task from the busiest_rq run queue to the target CPU run queue dst_rq.

[0056] This embodiment also includes a Linux-based preference suggestion scheduling system, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the Linux-based preference suggestion scheduling method described above.

[0057] This embodiment also includes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the Linux-based preference suggestion scheduling method described above.

[0058] This embodiment also includes a computer program product, comprising a computer program that, when executed by a processor, implements the steps of the Linux-based preference suggestion scheduling method described above.

[0059] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0060] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A preference-based scheduling method based on Linux, characterized in that, Includes the following steps: S1 extends the data structures of the Linux kernel by adding a member variable to the task structure to record task preference CPU information, and adding a member variable to the CPU run queue structure to count the total task load of the CPU in the CPU run queue, which includes the current CPU's preference CPU information. S2 provides system call interfaces and kernel-mode interfaces for setting the preferred CPU set for a specified task; S3, when the scheduler performs task enqueueing and dequeueing operations, dynamically update the total load of preferred CPUs in the CPU run queue structure according to whether the task has set a preferred CPU and whether the current CPU belongs to its preferred set. S4. When the scheduler selects a CPU to run a task, if the task has set a preferred CPU, the available CPU with the lightest load is selected from its preferred CPU set first; if the preferred CPUs are all unavailable or too heavily loaded, the task is selected from non-preferred CPUs to run. S5 prioritizes migrating tasks that do not have a preferred CPU when performing load balancing migration tasks; for tasks with a preferred CPU, prioritize migrating tasks whose target CPU is within their preferred set; only when the total load of the preferred CPU is saturated will tasks with a preferred CPU be migrated to their non-preferred CPU.

2. The Linux-based preference suggestion scheduling method according to claim 1, characterized in that, Step S1 specifically includes: Add the nr_cpus_preferred and cpus_preferred members to the struct task_struct structure to record the number of preferred CPUs and the set of CPU masks, respectively. Add the preferred_load and preferred_tasks members to the struct rq structure to record the preferred total CPU load and number of tasks in the current CPU run queue, respectively.

3. The Linux-based preference suggestion scheduling method according to claim 2, characterized in that, Step S1 also includes initializing nr_cpus_preferred to 0 and cpus_preferred to an empty mask during task initialization.

4. The Linux-based preference suggestion scheduling method according to claim 2, characterized in that, The system call interface mentioned in step S2 is sched_setpreferred, which receives the process identifier (PID) and a string representing the CPU set as parameters, including the following steps: S21, copy the CPU set string passed from user space and parse it into the kernel's cpumask type; S22, find the corresponding task structure based on the PID; S23, perform permission verification, and only allow the task itself or a process with CAP_SYS_NICE permission to modify it; S24, assign the parsed CPU mask to the cpus_preferred member of the task structure, and update its nr_cpus_preferred member.

5. A Linux-based preference-based scheduling method according to claim 2, characterized in that, Step S3 specifically includes: When a task is enqueued into the run queue of a CPU, if the nr_cpus_preferred member value of the task is greater than 0 and the current CPU number is within the cpus_preferred member value mask, then the load weight of the task is increased in the preferred_load member of the CPU's run queue, and the count value of the preferred_tasks member is incremented by 1. When a task is dequeued from the run queue of a CPU, if the nr_cpus_preferred member value of the task is greater than 0 and the current CPU number is within the cpus_preferred member value mask, then the preferred_load member value of the CPU's run queue is reduced by the load weight of the task, and the preferred_tasks member value count is decremented by 1.

6. The Linux-based preference suggestion scheduling method according to claim 2, characterized in that, Step S4 specifically includes: S41, Determine whether the nr_cpus_preferred member value of the task to be scheduled is greater than 0; S42, if so, iterate through all online CPUs in its cpus_preferred member value mask; S43, During the traversal, compare and record the CPU with the smallest preferred_load member value as the candidate CPU; S44. If a candidate CPU is found and the number of currently running tasks on the candidate CPU does not exceed its theoretical processing capacity, then the candidate CPU is selected as the running CPU; otherwise, the default CPU selection strategy is invoked.

7. A Linux-based preference-based scheduling method according to claim 2, characterized in that, Step S5 specifically includes: S51, sequentially traverse the tasks on the source CPU run queue, and check whether they need to be migrated. S52, determine whether the currently traversed task has set a CPU preference; if not, execute the default load balancing logic; if it has, execute step S53. S53, determine whether the target CPU belongs to the preferred CPU set of the task. If it does not belong, proceed to step S54; if it does belong, add the task to the list of tasks to be migrated and proceed to step S55. S54, Determine whether the total load of the preferred CPU for the task has reached the load saturation state. If it is saturated, add the task to the list of tasks to be migrated and execute step S55 to allow the task to migrate across the boundary to the non-preferred CPU. If it is not saturated, return to step S51 and continue to traverse other tasks. S55 migrates the task to the target CPU.

8. A Linux-based preference suggestion scheduling system, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the Linux-based preference prompting scheduling method as described in any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the Linux-based preference suggestion scheduling method as described in any one of claims 1-7.

10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the steps of the Linux-based preference prompting scheduling method according to any one of claims 1 to 7.

Images