A method and system for rapid scheduling and core allocation of multi-core server jobs

Abstract

The application relates to a multi-core server job quick scheduling and core allocation method and system, which comprises the following steps: step 1: a client sends a job request to a server, and the server receives and caches the job request; step 2: a scheduler takes out the job request and allocates a pre-created container pool to execute the job; step 3: a scheduling strategy is defined, and cores are dynamically allocated according to core load and the number of jobs; when the cores are transferred, the scheduler reallocates the cores; when the cores are preempted, a recovery mechanism is used to recover and execute the jobs, and the execution result is returned to the client. The application introduces an event-driven strategy customization interface, supports users to quickly define and apply personalized scheduling strategies, and designs a microsecond-level, low-overhead core preemption and reallocation mechanism, so that efficient dynamic adjustment of resources can be realized in multi-program parallel jobs, and therefore the system performance and resource utilization can be significantly improved.

Description

Technical Field

[0001] This invention relates to a method and system for fast scheduling and core allocation of multi-core server jobs, belonging to the field of computer technology. Background Technology

[0002] The widespread adoption of multi-core servers has driven the development of job scheduling and core allocation strategies. Early scheduling primarily relied on general algorithms within the operating system kernel, focusing on ensuring fairness and resource utilization. However, with the continuous increase in the number of cores, simple round-robin or load balancing has become insufficient to meet the demands of high-performance computing and data centers. In recent years, research has gradually shifted towards scheduling methods that are aware of cache hierarchy and thread affinity to reduce performance losses caused by cross-core and cross-NUMA node communication. Simultaneously, scheduling strategies for heterogeneous cores and massively parallel processing are constantly evolving, making job allocation more intelligent and refined.

[0003] With the widespread adoption of multi-core CPUs and cloud computing environments, efficiently utilizing limited core and cache resources in multi-job scenarios has become a crucial performance optimization issue. Traditional job scheduling methods have the following limitations: 1. High job startup overhead: The execution environment needs to be reinitialized every time a job is started, resulting in uncontrollable response time.

[0004] 2. The scheduling strategy is singular and difficult to customize: Most systems adopt static or fixed strategies, which are difficult to adjust flexibly for different job loads and resource states.

[0005] 3. High latency in preemption and resource reallocation: Existing methods suffer from lock contention and state transition latency when preempting across job threads, affecting microsecond-level performance requirements.

[0006] 4. Low efficiency of work stealing and recovery: Traditional work stealing strategies do not make full use of thread legacy tasks, resulting in redundant overhead and performance loss.

[0007] Therefore, a multi-core scheduling framework is needed that can support dynamic job arrival, low-overhead container reuse, microsecond-level core reallocation, and efficient thread recovery, while providing policy customization interfaces to meet different application scenarios and administrator needs. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this invention provides a method and system for fast scheduling and core allocation of multi-core server jobs. By constructing a unified scheduling framework, it achieves collaborative management of processor cores, cache, and memory bandwidth to solve resource contention issues during multi-program execution. This method introduces an event-driven policy customization interface, allowing users to quickly define and apply personalized scheduling policies. Simultaneously, it designs a microsecond-level, low-overhead core preemption and reallocation mechanism to achieve efficient dynamic resource adjustment in parallel multi-program operations, thereby significantly improving system performance and resource utilization.

[0009] Terminology Explanation: 1. FIFO buffer: A first-in-first-out queue-style buffer mechanism, often used for data transmission or multi-threaded communication to ensure that the writing and reading order is consistent.

[0010] 2. Scheduler: A core module of the operating system or runtime, responsible for allocating CPU time slices and determining when and where threads or jobs run. It is key to multi-core resource management.

[0011] 3. THE Protocol: An early multi-process mutual exclusion protocol that guarantees mutual exclusion by strictly ordering entry into the critical section, but it is less efficient and is mainly of educational and historical significance.

[0012] 4. Intel RDT Interface: A hardware support interface provided by Intel that can allocate and monitor cache and memory bandwidth to optimize resource isolation in multi-tenant and high-performance scenarios.

[0013] 5. Parallelism: In computer science, parallelism is a key indicator for measuring the parallel processing capability of a system. It refers to the maximum number of tasks that can be executed simultaneously at the instruction or data level. The technical solution of the present invention is as follows: The first aspect of this invention provides a method for fast scheduling and core allocation of multi-core server jobs, comprising: Step 1: The client sends the job request to the server, and the server receives and caches the job request; Step 2: The scheduler retrieves job requests and allocates them to a pre-created container pool for execution. Step 3: Define the scheduling strategy to dynamically allocate cores based on core load and the number of jobs; When a core is transferred, the scheduler performs core reallocation; When a core is preempted, the job is resumed and executed through the recovery mechanism, and the execution result is returned to the client.

[0014] According to a preferred embodiment of the present invention, the client sends a job request to the server, and the server receives and caches the job request; including: The client generates a job request, including job program identification information and input parameters, i.e., the parameters required to start the program; The client sends a job request to the server. The server receives the job request and continuously listens to the client. The received job requests are stored in a FIFO buffer in sequence.

[0015] According to a preferred embodiment of the present invention, the scheduler retrieves job requests and allocates pre-created container pools to execute the jobs, including: The server pre-creates a container pool, which includes multiple containers; The scheduler retrieves job requests sequentially from the FIFO buffer, allocates the corresponding jobs to idle containers according to the job requests, and allocates the required computing resources, i.e., core execution jobs.

[0016] According to a preferred embodiment of the present invention, a scheduling strategy is defined to dynamically allocate cores based on core load and the number of jobs; including: Define scheduling policies and obtain monitoring information during job execution, including core utilization, cache access statistics, and memory bandwidth usage. When a new job arrives, if there are n_t unfinished jobs in the current system, each core is assigned to the new job with a probability of 1 / n_t. When a job completes, the scheduler releases the core resources occupied by the job and readjusts the core allocation scheme according to the currently unfinished jobs. This includes, if there are jobs with insufficient parallelism (i.e., the number of cores that should be allocated is greater than the number of cores currently in use), the released core resources are allocated to the jobs with insufficient parallelism first; otherwise, the cores are redistributed according to the established probability rule of 1 / n_t. The scheduler adjusts core allocation based on monitoring information during job execution and real-time load conditions; including reducing the number of cores by 10% for jobs with CPU utilization below 50%, and increasing the number of cores by 10% for jobs with resource contention or CPU utilization consistently exceeding 80%; in order to maintain the overall operational stability and resource balance of the system. When an external scheduler requests an adjustment to the core quota, the scheduler performs core addition or reduction operations on the relevant jobs according to the instructions. This includes triggering a safety pause and releasing cores for jobs that need to reduce cores, and allowing jobs that need to increase cores to obtain available cores and resume execution.

[0017] According to a preferred embodiment of the present invention, when a core is transferred, the scheduler performs core reallocation; including: When the scheduler moves the core from job A to job B according to the scheduling policy, a threshold T is set, and the exception pointer E of job A is set to be greater than the threshold T to trigger a safe pause. After job A finishes executing its current function, it checks the exception pointer E. If it is greater than the set threshold T, it enters exception handling, that is, marks the current job's thread as sleeping and releases the core, and uses the THE protocol to transfer the core to job B; otherwise, it continues to execute the job.

[0018] According to a preferred embodiment of the present invention, when a core preemption occurs, a recovery mechanism is used to resume and execute the job, and the execution result is returned to the client; including: When a core is preempted, the preempted job thread is marked and recorded in the server-side status array based on whether there are any outstanding tasks or incomplete tasks. If there are incomplete tasks in the job thread, it is marked as inactive_with_work; if there are no incomplete tasks in the job thread, it is marked as inactive_without_work. Active threads are job threads that have not been preempted and are still executing tasks. They scan all state arrays. After an active thread finishes its own task, it will take priority to execute the tasks in worker threads marked as inactive_with_work. When job threads execute job tasks on a core, only one job thread runs on each core at a time; at the same time, the scheduler allocates cache and memory bandwidth to the core through the Intel RDT interface. After the job is completed, the scheduler checks the job status and generates result data; The server returns the job results to the client, and the client then submits new jobs after receiving the results.

[0019] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program implementing steps of a method for fast scheduling and core allocation of multi-core server jobs.

[0020] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of a method for fast scheduling and core allocation of multi-core server jobs.

[0021] A second aspect of the present invention provides a multi-core server job fast scheduling and core allocation system, comprising: The job caching module is configured such that: the client sends a job request to the server, and the server receives the job request and caches it; The container pool allocation module is configured to: retrieve job requests from the scheduler and allocate them to pre-created container pools for job execution; The scheduling policy execution module is configured to: define scheduling policies and dynamically allocate cores based on core load and the number of jobs; When a core is transferred, the scheduler performs core reallocation; When a core is preempted, the job is resumed and executed through the recovery mechanism, and the execution result is returned to the client.

[0022] The beneficial effects of this invention are as follows: 1. This invention achieves rapid job startup and execution through a client-server architecture and container reuse mechanism, significantly reducing job startup overhead. Through a pre-allocated container pool, jobs can be allocated resources and started execution within microseconds, thereby improving the overall task throughput and response speed of multi-core servers.

[0023] 2. This invention provides a flexible strategy customization interface, allowing system administrators to dynamically adjust job scheduling and core allocation strategies based on runtime information. Users can define custom scheduling rules, such as Probabilistic Core Allocation (DREP), to achieve optimal scheduling for different job loads and core utilization rates, thereby improving resource utilization efficiency and system performance.

[0024] 3. This invention designs a decentralized scheduler and a fast core reallocation mechanism to decouple job threads from the core. Through microsecond-level core preemption and thread-safe pausing, the system can dynamically adjust resource allocation. At the same time, through an efficient job recovery mechanism (Mugging), it ensures that the legacy tasks of preempted threads are quickly migrated and restored, avoiding resource waste and thread conflicts.

[0025] 4. This invention is applicable to multi-core servers and cloud computing environments, and can support external schedulers to dynamically control resources (such as limiting the number of cores and subscribing to runtime information), ensuring stable execution of jobs in high-concurrency, multi-job scenarios. Experimental results show that this invention can achieve microsecond-level resource adjustment, significantly improving job processing efficiency and system throughput. Attached Figure Description

[0026] Figure 1 This is a flowchart of the multi-core server job fast scheduling and core allocation method of the present invention. Detailed Implementation

[0027] The present invention will be further described below with reference to the embodiments and accompanying drawings, but is not limited thereto.

[0028] Example 1 A method for fast scheduling and core allocation of multi-core server jobs, such as Figure 1 As shown, it includes: Step 1: The client sends the job request to the server, and the server receives and caches the job request; Step 2: The scheduler retrieves job requests and allocates them to a pre-created container pool for execution. Step 3: Define the scheduling strategy to dynamically allocate cores based on core load and the number of jobs; When a core is transferred, the scheduler performs core reallocation; When a core is preempted, the job is resumed and executed through the recovery mechanism, and the execution result is returned to the client.

[0029] Example 2 The difference between the fast scheduling and core allocation method for multi-core server jobs described in Example 1 and the method described in Example 1 is as follows: The client sends a job request to the server, which receives and caches the job request; this includes: The client generates a job request, which includes job program identification information (program ID, which identifies which program needs to be run) and input parameters, i.e. the parameters required to start the program, such as dataset path, computation scale, configuration options, etc. The client sends job requests to the server, supporting concurrent submission of multiple jobs and ensuring request order and transmission reliability. The server receives job requests and continuously listens to the client (the server sets up at least one dedicated thread, bound to a fixed core, and continuously listens to the job requests submitted by the client to ensure job order and timeliness); the received job requests are stored sequentially into a FIFO buffer.

[0030] The scheduler retrieves job requests and allocates them to a pre-created container pool for execution, including: The server pre-creates a container pool, which includes multiple containers (a container is a virtualization technology used to package an application and all its dependencies together for portability and operation in different computing environments; the container pool is kept in a pre-initialized state, with containers having completed resource allocation, runtime structure initialization, and other steps, ready to be loaded and run the main function at any time, and can be reused using Docker containers or lightweight screen sessions); when a new job arrives, there is no need to recreate the container, but instead an idle container is directly allocated, significantly reducing job startup latency; the container pool is kept in a pre-initialized state, with containers having completed resource allocation, runtime structure initialization, and other steps, ready to be loaded and run the main function at any time; The scheduler sequentially retrieves job requests from the FIFO buffer. Based on the job request, it allocates the corresponding job (which refers to a complete computing task that needs to be run on the server, such as a parallel program or application instance) to an idle container and allocates the required computing resources, i.e., the core execution job (such as calling the job's cilk_main function). It supports dynamic job arrival and completion without needing to know the number or type of jobs in advance. The container pool is pre-initialized and kept active to reduce job startup overhead (approximately 295μs in actual testing).

[0031] Define a scheduling strategy to dynamically allocate cores based on core load and the number of jobs; including: Define the scheduling policy (policy function job_scheduler(e)) and obtain monitoring information during job execution, including core utilization, cache access statistics, and memory bandwidth usage; the scheduling policy includes new job arrival (START_JOB), job completion (EXIT_JOB), timed triggering (TIMER), and external resource request (REQUESTED). When a new job arrives, if there are n_t unfinished jobs in the current system, each core is assigned to the new job with a probability of 1 / n_t to ensure fair allocation. When a job completes, the scheduler releases the core resources occupied by the job and readjusts the core allocation scheme based on the currently incomplete jobs. This includes, if there are jobs with insufficient parallelism (i.e., the number of cores that should be allocated is greater than the number of cores currently in use), then the released core resources are allocated to jobs with insufficient parallelism first; otherwise, (if the system load balances, and the number of allocated cores is balanced with the number of cores used), the cores are redistributed according to a predetermined probability rule of 1 / n_t to maintain the fairness and continuity of resource use. The scheduler adjusts core allocation based on monitoring information during job execution and real-time load conditions; for jobs with CPU utilization below 50%, the scheduler reduces the number of cores by 10%, and for jobs with resource contention or CPU utilization exceeding 80% for a sustained period (e.g., 30 seconds), the scheduler increases the number of cores by 10%; in order to maintain the overall operational stability and resource balance of the system. When an external scheduler requests an adjustment to the core quota, the scheduler performs core addition or reduction operations on the relevant jobs according to the instructions. This includes triggering a safety pause and releasing cores for jobs that need to reduce cores, and allowing jobs that need to increase cores to obtain available cores and resume execution. This process ensures task queue consistency according to the THE protocol and avoids resource contention and scheduling conflicts.

[0032] When a core is migrated, the scheduler performs core reallocation; this includes: While ensuring safety, switch the physical core x from job A to job B as responsively as possible to minimize migration overhead and impact on job correctness; When the scheduler moves cores from job A to job B according to the scheduling policy (job A and job B are any two different jobs), if the new job arrives and system resources are scarce, some cores need to be reclaimed from existing jobs to meet the parallelism of the new job; if a job becomes a high-priority or real-time requirement, more cores need to be allocated; the external scheduler adjusts the resource quota of AMCilk; a threshold T is set, and the exception pointer E of job A is set to be greater than the threshold T to trigger a safe pause. After job A finishes executing its current function (the function that runs when executing the current job task), it checks the exception pointer E. If it is greater than the set threshold T (a core transfer is required), it enters exception handling, that is, marks the current job's thread as sleeping and releases the core. Using the THE protocol, the core is transferred to job B, achieving microsecond-level core switching; otherwise, the job continues to execute.

[0033] Under the THE protocol, the scheduler only needs to update the T / H / E or abnormal frame position of queue B within the atomic region and add the task frames that need to be recovered or newly allocated to queue B. If job B has a saved frame (due to an error / preemption), the worker will restore the frame from the specified position in job E and continue execution according to the recovery mechanism. If no frame is saved, perform a pop operation on B's queue or perform a steal operation on another worker to obtain B's task frame; Continue execution on the same OS thread: The worker keeps the OS thread unchanged, only switching its currently executing task in user mode; When core preemption occurs, the recovery mechanism resumes and executes the job, returning the execution result to the client; including: When a core preemption occurs (such as when an interrupt is triggered, CPU resources are reallocated, or the scheduler switches the core from job A to job B), the preempted job thread is marked and recorded in the server-side status array based on whether there are any outstanding tasks. If there are outstanding tasks in the job thread, it is marked as inactive_with_work; if there are no outstanding tasks in the job thread, it is marked as inactive_without_work, so that it can be resumed later. Active threads, which are job threads that have not been preempted and are still executing tasks, scan all state arrays. After an active thread finishes its own task, it prioritizes executing tasks in worker threads marked as inactive_with_work; this implements non-stealing task migration; and updates the worker array pointer to avoid duplicate or invalid task theft, ensuring that only active threads participate in work recovery. Mugging operations have lower overhead than traditional stealing (0.363μs vs 1.44μs), improving thread recovery efficiency and maintaining the asymptotic optimality of work stealing; When job threads execute job tasks on cores, they support multi-threaded concurrent computation, ensuring that only one job thread runs on each core at a time. Meanwhile, the scheduler allocates cache and memory bandwidth to cores through the Intel RDT interface to achieve resource isolation and performance optimization between jobs. After the job is completed, the scheduler checks the job status and generates result data; The server returns the job results to the client, realizing closed-loop job processing. After receiving the results, the client continues to submit new jobs, forming a dynamic loop.

[0034] 1. Client submits job 1-1 Job Request Generation Generate a job script job1.sh on the client terminal with the following content: #! / bin / bash stress-ng --cpu 2 --timeout 10s" 1-2 Job Request Submission Use commands to submit the job to the server via a pipe (assuming the server is listening on / tmp / job_pipe): mkfifo / tmp / job_pipe echo " / home / user / job1.sh"> / tmp / job_pipe The client can continue to submit scripts such as job2.sh and job3.sh, forming a multi-job scenario: echo " / home / user / job2.sh"> / tmp / job_pipe echo " / home / user / job3.sh"> / tmp / job_pipe 2. Server receives and buffers 2-1 Request Listening The server starts a dedicated listening thread (or a background script): cat / tmp / job_pipe | while read job_path; do echo "$job_path">> / tmp / job_queue done& At this point, the / tmp / job_queue file serves as a FIFO buffer to store jobs to be executed.

[0035] 2-2 Work Buffer The server retrieves jobs sequentially from / tmp / job_queue: while reading job_path; do # Subsequent Scheduling echo "Received job: $job_path" done < / tmp / job_queue 3. The scheduler starts the container. 3-1 Container Pool Reuse The server pre-creates a container pool (which can be reused using Docker containers or lightweight screen sessions): # Assuming a screen session reuse container is used screen -dmS container1 screen -S container1 -X stuff "echo 'Container ready\n'" 3-2 Operation Start After reading the job from the queue, schedule the job to be executed in the container: while reading job_path; do screen -S container1 -X stuff "bash $job_path\n" done < / tmp / job_queue The startup time is approximately 295 μs (microscopic measurement).

[0036] 4. Strategy Customization Interface Decision The administrator defines a policy script, scheduler.sh, to dynamically allocate cores based on CPU load and the number of jobs. #! / bin / bash # scheduler.sh: Simple DREP strategy # Get the number of incomplete assignments n_t=$(wc -l < / tmp / job_queue) for job_path in $(cat / tmp / job_queue); do # Randomly select core core=$(( RANDOM % 4 )) taskset -c $core bash $job_path& done Operational strategy: bash scheduler.sh 5 Core Redistribution 5-1 Preemption Trigger When high-priority jobs arrive, cores can be reallocated using taskset: # Move PID 1234 from core 1 to core 2 taskset -cp 2 1234 5-2 Safety Pause In a Linux environment, you can use `kill -STOP` to pause a process. kill -STOP 1234 # Waiting for the scheduler to reallocate cores kill -CONT 1234 5-3 Core Activation Once the new job thread is awakened, it continues execution on the target core: taskset -cp 1 5678 # Allocate to the new core 6. Job Execution The job runs on the allocated cores, and the screen session guarantees thread isolation, with only one job thread running on each core at a time. # Check the running status of each core htop 7. Results are returned to the client. After the task is completed, the results are written back to the client via a pipe: echo "Job 1 completed"> / tmp / result_pipe cat / tmp / result_pipe 8. Work resumption mechanism 8-1 Status Flags The status of the preempted job thread is recorded on the server side: echo "1234:inactive_with_work">> / tmp / thread_state 8-2 Mugging Operation Active threads scan the state array and prioritize restoring legacy tasks: while read line; do pid=$(echo $line | cut -d: -f1) status=$(echo $line | cut -d: -f2) if [ "$status" == "inactive_with_work" ]; then kill -CONT $pid fi done < / tmp / thread_state 8-3 Performance Optimization Mugging operations involve only a small number of PID operations, and the overhead is far lower than global thread stealing.

[0037] This invention enables rapid client job submission, server buffering, container reuse and startup, policy-customized scheduling, microsecond-level core reallocation, and efficient job recovery in multi-core Ubuntu systems. This implementation verifies the feasibility of the invention's low-overhead dynamic scheduling capabilities, flexible policy control, and concurrent execution of multiple jobs, providing an effective technical means for efficient resource management in multi-core servers and cloud computing environments.

[0038] Example 3 A computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the multi-core server job fast scheduling and core allocation method described in Embodiment 1 or 2.

[0039] Example 4 A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the multi-core server job fast scheduling and core allocation method described in Embodiment 1 or 2.

[0040] Example 5 A multi-core server job fast scheduling and core allocation system includes: The job caching module is configured such that: the client sends a job request to the server, and the server receives the job request and caches it; The container pool allocation module is configured to: retrieve job requests from the scheduler and allocate them to pre-created container pools for job execution; The scheduling policy execution module is configured to: define scheduling policies and dynamically allocate cores based on core load and the number of jobs; When a core is transferred, the scheduler performs core reallocation; When a core is preempted, the job is resumed and executed through the recovery mechanism, and the execution result is returned to the client.

Claims

1. A method for fast job scheduling and core allocation on a multi-core server, characterized in that, include: Step 1: The client sends the job request to the server, and the server receives and caches the job request; Step 2: The scheduler retrieves job requests and allocates them to a pre-created container pool for execution. Step 3: Define the scheduling strategy to dynamically allocate cores based on core load and the number of jobs; When a core is transferred, the scheduler performs core reallocation; When a core is preempted, the job is resumed and executed through the recovery mechanism, and the execution result is returned to the client.

2. The method for fast scheduling and core allocation of multi-core server jobs according to claim 1, characterized in that, The client sends a job request to the server, which receives and caches the job request; this includes: The client generates a job request, including job program identification information and input parameters, i.e., the parameters required to start the program; The client sends a job request to the server. The server receives the job request and continuously listens to the client. The received job requests are stored in a FIFO buffer in sequence.

3. The method for fast scheduling and core allocation of multi-core server jobs according to claim 2, characterized in that, The scheduler retrieves job requests and allocates them to a pre-created container pool for execution, including: The server pre-creates a container pool, which includes multiple containers; The scheduler retrieves job requests sequentially from the FIFO buffer, allocates the corresponding jobs to idle containers according to the job requests, and allocates the required computing resources, i.e., core execution jobs.

4. The method for fast scheduling and core allocation of multi-core server jobs according to claim 3, characterized in that, Define a scheduling strategy to dynamically allocate cores based on core load and the number of jobs; including: Define scheduling policies and obtain monitoring information during job execution, including core utilization, cache access statistics, and memory bandwidth usage; When a new job arrives, if there are n_t unfinished jobs in the current system, each core is assigned to the new job with a probability of 1 / n_t. When a job completes, the scheduler releases the core resources occupied by the job and readjusts the core allocation scheme according to the currently unfinished jobs. This includes, if there are jobs with insufficient parallelism (i.e., the number of cores that should be allocated is greater than the number of cores currently in use), the released core resources are allocated to the jobs with insufficient parallelism first; otherwise, the cores are redistributed according to the established probability rule of 1 / n_t. The scheduler adjusts core allocation based on monitoring information during job execution and real-time load conditions; When an external scheduler requests an adjustment to the core quota, the scheduler performs core addition or reduction operations on the relevant jobs according to the instructions. This includes triggering a safety pause and releasing cores for jobs that need to reduce cores, and allowing jobs that need to increase cores to obtain available cores and resume execution.

5. The method for fast scheduling and core allocation of multi-core server jobs according to claim 4, characterized in that, When a core is migrated, the scheduler performs core reallocation; this includes: When the scheduler moves a core from job A to job B according to the scheduling policy, a threshold T is set, and the exception pointer E of job A is set to be greater than the threshold T. After job A finishes executing its current function, it checks the exception pointer E. If it is greater than the set threshold T, it enters exception handling, that is, marks the current job's thread as sleeping and releases the core, and uses the THE protocol to transfer the core to job B; otherwise, it continues to execute the job.

6. The method for fast scheduling and core allocation of multi-core server jobs according to claim 5, characterized in that, When core preemption occurs, the recovery mechanism resumes and executes the job, returning the execution result to the client; including: When a core is preempted, the preempted job thread is marked and recorded in the server-side status array based on whether there are any outstanding tasks or incomplete tasks. If there are incomplete tasks in the job thread, it is marked as inactive_with_work; if there are no incomplete tasks in the job thread, it is marked as inactive_without_work. Active threads are job threads that have not been preempted and are still executing tasks. They scan all state arrays. After an active thread finishes its own task, it will take priority to execute the tasks in worker threads marked as inactive_with_work. When job threads execute job tasks on a core, only one job thread runs on each core at a time; at the same time, the scheduler allocates cache and memory bandwidth to the core through the Intel RDT interface. After the job is completed, the scheduler checks the job status and generates result data; The server returns the job results to the client, and the client then submits new jobs after receiving the results.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the multi-core server job fast scheduling and core allocation method according to any one of claims 1-6.

8. 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 fast scheduling and core allocation method for multi-core server jobs as described in any one of claims 1-6.

9. A multi-core server job fast scheduling and core allocation system, characterized in that, include: The job caching module is configured such that: the client sends a job request to the server, and the server receives the job request and caches it; The container pool allocation module is configured to: retrieve job requests from the scheduler and allocate them to pre-created container pools for job execution; The scheduling policy execution module is configured to: define scheduling policies and dynamically allocate cores based on core load and the number of jobs; When a core is transferred, the scheduler performs core reallocation; When a core is preempted, the job is resumed and executed through the recovery mechanism, and the execution result is returned to the client.

Images