Resource scheduling method and device, electronic equipment and storage medium

Abstract

This invention relates to a resource scheduling method, apparatus, electronic device, and storage medium, comprising: selecting any CPU as the foreground CPU and the other CPUs as background CPUs in a target system with multiple CPUs; obtaining a target task to be processed; performing software and hardware task parsing on the target task to obtain a software task and a hardware task to be processed; and performing software and hardware resource scheduling on the software task and hardware task through a unified software interface and / or hardware interface to process the target task. Therefore, it supports FTL software in uniformly scheduling and managing different hardware resources inside an SSD when there are multiple CPU cores, and FTL developers can use a unified interface to call different types of internal hardware resources.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of software and hardware resource scheduling technology, and in particular to a resource scheduling method, apparatus, electronic device and storage medium. Background Technology

[0002] The File Translator (FTL) is the core software control layer of a Solid State Drive (SSD). Its algorithms and implementation directly determine the SSD's reliability, performance, and durability. Its core function is to translate host logical addresses to flash memory physical addresses and control the execution and feedback of host commands, including read, write, trim, format, and power-on / off. Because NAND flash storage media has a high-dimensional structure different from the linear address space defined by the front-end command standard and lacks write overwrite capabilities, it must be erased in blocks. This necessitates strict management of the related workflow by the FTL. Most current SSD products include the aforementioned FTL software in their firmware to specifically schedule the collaborative work of different types of NAND, caching hardware, and other hardware algorithm modules. Most mainstream products currently employ the following basic operating mode: multi-threaded asynchronous operation; message queue communication between software and hardware modules; independent state machines for each functional module; and parallel execution between modules via pipelines.

[0003] However, the aforementioned FTL software needs to be designed for the specific available resources contained in the SSD product. For example, different numbers of internal CPU cores may lead software designers to adopt completely different usage strategies for each CPU core; different internal cache sizes will also lead designers to use completely different cache usage strategies; due to inconsistent hardware calling interfaces and the mixed distribution of software and hardware code, specific calling patterns must be used in the software code to call different hardware. This makes the FTL's calling of different hardware resources inside the SSD very cumbersome, time-consuming, and inefficient when there are multiple CPU cores. Summary of the Invention

[0004] In view of this, in order to solve the above-mentioned technical problems or some of the technical problems, the embodiments of the present invention provide a resource scheduling method, apparatus, electronic device and storage medium.

[0005] In a first aspect, embodiments of the present invention provide a resource scheduling method, including:

[0006] In a target system with multiple CPUs, select any one CPU as the foreground CPU and the other CPUs as background CPUs.

[0007] Obtain the target task to be processed;

[0008] The target task is parsed to obtain the software task and hardware task to be processed.

[0009] The software and hardware tasks are processed by scheduling software and hardware resources through a unified software interface and / or hardware interface to handle the target task.

[0010] In one possible implementation, the method further includes:

[0011] The software task is assigned to at least one background CPU through a unified software interface, and the hardware task is assigned to a hardware processing module through a unified hardware interface, so that the hardware processing module can perform hardware resource scheduling for the target task.

[0012] In one possible implementation, the method further includes

[0013] Set corresponding software memory requirements and hardware memory requirements for the software tasks and hardware tasks respectively;

[0014] Based on the memory requirements, select a target background CPU and a target solid-state drive that meet the preset conditions from other CPUs;

[0015] The software tasks are assigned to the target backend CPU through a unified software interface, and the hardware tasks are assigned to the hardware processing module located inside the target solid-state drive through a unified hardware interface.

[0016] In one possible implementation, the method further includes:

[0017] Based on the software memory requirements, a first target memory region is allocated to the target background CPU, and based on the hardware memory requirements, a second target memory region is allocated to the target solid-state drive.

[0018] In one possible implementation, the method further includes:

[0019] Receive the task reception result returned by the target background CPU and the hardware processing module;

[0020] If the target background CPU or the hardware processing module has insufficient resources, the task reception result will be a failure.

[0021] The software tasks that fail to be received by the target background CPU are run in the foreground CPU, and the hardware tasks that fail to be received by the hardware processing module are cached until the hardware processing module has sufficient resources to continue processing the hardware tasks.

[0022] In one possible implementation, the method further includes:

[0023] If the target background CPU has sufficient resources, the task reception result is successful;

[0024] Receive the task reception result of the target background CPU for the software task;

[0025] If the task reception result is successful, then receive the result that the task processing is completed returned by the target background CPU;

[0026] If the task reception result is a failure, then the software task with the failed task reception result will be run in the foreground CPU.

[0027] In one possible implementation, the method further includes:

[0028] Based on a first first-in-first-out queue of one waiting task maintained by each background CPU and a second first-in-first-out queue of multiple tasks that have completed execution and are waiting for the foreground CPU to query the execution results, the running status of each background CPU is determined, wherein the running status refers to the number of software tasks waiting to be executed in the task queue of each background CPU.

[0029] The system determines whether there are idle channels in the hardware processing module based on a preset data structure.

[0030] In a second aspect, embodiments of the present invention provide a resource scheduling device, comprising:

[0031] The configuration module is used to select any CPU as the foreground CPU and the other CPUs as background CPUs in a target system with multiple CPUs.

[0032] The acquisition module is used to acquire the target task to be processed;

[0033] The parsing module is used to parse the target task into software and hardware tasks to obtain the software and hardware tasks to be processed.

[0034] The scheduling module is used to schedule software and hardware resources for the target task through a unified software interface and / or hardware interface.

[0035] Thirdly, embodiments of the present invention provide a server, including a processor and a memory, wherein the processor is configured to execute a resource scheduling program stored in the memory to implement the resource scheduling method described in the first aspect above.

[0036] Fourthly, embodiments of the present invention provide a storage medium, comprising: the storage medium storing one or more programs, the one or more programs being executable by one or more processors to implement the resource scheduling method described in the first aspect above.

[0037] The resource scheduling scheme provided in this invention selects any CPU as the foreground CPU and the others as background CPUs in a target system with multiple CPUs; obtains the target task to be processed; performs software and hardware task parsing on the target task to obtain the software task and hardware task to be processed; and schedules software and hardware resources for the software task and hardware task through a unified software interface and / or hardware interface to process the target task. Compared with the existing technology where FTL software has cumbersome, time-consuming, and inefficient calls to different hardware resources inside the SSD when it has multiple CPU cores, this scheme supports unified scheduling and management of different hardware resources inside the SSD when FTL software has multiple CPU cores. FTL developers can use a unified interface to call different types of internal hardware resources. Attached Figure Description

[0038] Figure 1 A schematic diagram of a resource scheduling system architecture provided in an embodiment of the present invention;

[0039] Figure 2 A flowchart illustrating a resource scheduling method provided in an embodiment of the present invention;

[0040] Figure 3 A schematic diagram of S24 provided in an embodiment of the present invention;

[0041] Figure 4 This is a schematic diagram of the structure of a resource scheduling device provided in an embodiment of the present invention;

[0042] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0044] To facilitate understanding of the embodiments of the present invention, further explanations and descriptions will be provided below with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of the present invention.

[0045] Figure 1 This is a schematic diagram of a resource scheduling system architecture provided by an embodiment of the present invention, such as... Figure 1As shown, the resource scheduling system in this invention adopts a master-slave working mode. The master-slave mode is a parallel software working mode, and the working state is divided into foreground (master) and background (slave). The foreground is responsible for allocating computing tasks and storage resources, while the background is responsible for executing the computing tasks.

[0046] Specifically, the master CPU resides on a fixed CPU core, while other CPU cores act as slaves. When the master enters an idle state, it can switch to a slave to execute tasks. The entire workflow is maintained by the master, which is responsible for defining slave tasks, hardware operations, and host commands. Only the master has the authority to schedule slaves to execute tasks, initiate hardware operations, and obtain host commands. Memory management is entirely handled by the master, which is responsible for transferring specific memory regions to slaves or specific hardware processing modules for task execution. Dependencies between tasks are maintained by the developers based on memory access requirements; thread locks are not used. The system limits the memory requirements of various tasks. Upon receiving a task processing command, the master first decomposes the task to accommodate memory requirements, disallowing dynamic memory allocation for tasks to avoid memory errors.

[0047] Figure 2 This is a flowchart illustrating a resource scheduling method provided in an embodiment of the present invention, as shown below. Figure 2 As shown, the method specifically includes:

[0048] S21. In a target system with multiple CPUs, select any CPU as the foreground CPU and the other CPUs as background CPUs.

[0049] This invention applies to a general-purpose parallel computing platform to support unified scheduling and management of different hardware resources within an SSD when the FTL software has multiple CPU cores. Based on this platform, FTL developers can use a unified interface to call different types of internal hardware resources. A master-slave working mode is adopted. The master-slave mode is a parallel software working mode where the working state is divided into a foreground (master) and a background (slave). The foreground is responsible for allocating computing tasks and storage resources, while the background is responsible for executing the actual computing tasks.

[0050] First, in a target system with multiple CPUs, one CPU can be arbitrarily set as the foreground CPU (master), and the other CPUs can be set as background CPUs (slave).

[0051] S22. Obtain the target task to be processed.

[0052] The foreground CPU (master) receives task processing commands, which carry the target task to be processed. Generally, the target task includes both software and hardware tasks. Software tasks need to be processed on the background CPU (slave), while hardware tasks need to be processed on specific types of hardware processing modules.

[0053] The types of hardware processing modules may include: Nand to FTL memory data transfer module; FTL memory to Nand data transfer module; Nand data erasure module; DMA copy module from Host memory to FTL memory; DMA copy module from FTL memory to Host memory; direct data transfer module from Nand to Host memory; and algorithm module for performing XOR operations on block data.

[0054] Among them, NAND refers to the actual physical storage medium inside the solid-state drive; Host memory refers to the memory controlled by the host operating system connected to the solid-state drive; FTL memory refers to the memory managed by the software control layer inside the solid-state drive.

[0055] S23. Perform software and hardware task analysis on the target task to obtain the software task and hardware task to be processed.

[0056] Generally, the target task includes both software and hardware tasks. The received target task is parsed to obtain the software and hardware tasks to be processed. The number of software and hardware tasks can be one or more.

[0057] S24. The software and hardware tasks are scheduled using a unified software interface and / or hardware interface to process the target task.

[0058] In this embodiment of the invention, as developers continuously submit new tasks to the platform, the working status of each background CPU (slave) and the hardware processing module located inside the solid-state drive is updated accordingly. Each background CPU (slave) maintains a queue of software tasks waiting to be executed and records the length of the queue. Each hardware processing module maintains a specific data structure to manage the idle state of the task execution channel.

[0059] Furthermore, software tasks are assigned to the background CPU (slave) with the fewest queued software tasks or forcibly specified by the developer through a unified software interface, and hardware tasks are assigned to the hardware processing module inside the solid-state drive through a unified hardware interface. A preset data structure is used to determine whether there is an idle channel in the hardware processing module. If there is, the hardware task is assigned to the idle channel so that the solid-state drive can process the target task.

[0060] Each background CPU maintains a first-in-first-out (FIFO) queue for tasks waiting to run and several other first-in-first-out (FIFO) queues for completed tasks, determined by the type of software task, awaiting the results from the foreground CPU. Each type of hardware processing module can execute multiple hardware tasks in parallel, with each executable hardware task corresponding to a channel. Each type of hardware processing module maintains a data structure indicating whether each of its channels is idle, and supports traversing the next idle channel within a constant time.

[0061] The resource scheduling method provided in this invention involves selecting any CPU as the foreground CPU and the others as background CPUs in a target system with multiple CPUs; obtaining the target task to be processed; performing software and hardware task parsing on the target task to obtain the software task and hardware task to be processed; and scheduling software and hardware resources for the software task and hardware task through a unified software interface and / or hardware interface to process the target task. Compared to the cumbersome, time-consuming, and inefficient calling of different hardware resources inside the SSD by FTL software when it has multiple CPU cores in the prior art, this method supports unified scheduling and management of different hardware resources inside the SSD by FTL software when it has multiple CPU cores. FTL developers can use a unified interface to call different types of internal hardware resources.

[0062] Figure 3 This is a flowchart illustrating step S24 of an embodiment of the present invention, as shown below. Figure 3 As shown, it specifically includes:

[0063] S31. Set the corresponding software memory requirements and hardware memory requirements for the software task and hardware task respectively.

[0064] In this embodiment of the invention, after receiving the task processing command, the foreground CPU (master) first decomposes the target task to be processed into software tasks and hardware tasks to be processed. The memory requirements of various tasks are restricted, and dynamic allocation of memory for tasks is not allowed to avoid memory errors. Therefore, the corresponding software memory requirements and hardware memory requirements can be set for software tasks and hardware tasks respectively according to the actual processing situation and resource situation.

[0065] S32. Based on the memory requirements, select a target background CPU and a target solid-state drive that meet the preset conditions from the other CPUs.

[0066] In this embodiment of the invention, as developers continuously submit new tasks to the platform, the working status of each background CPU (slave) and the hardware processing module located inside the solid-state drive is updated accordingly. Each background CPU (slave) maintains a queue of software tasks waiting to be executed and records the length of the queue. Each hardware processing module maintains a specific data structure to manage the idle state of the task execution channel.

[0067] Select the background CPU (Slave) with the fewest queued tasks and the idle channel of each hardware processing module to process the target task.

[0068] S33. Allocate a first target memory region to the target background CPU based on the software memory requirements, and allocate a second target memory region to the target solid-state drive based on the hardware memory requirements.

[0069] Before allocating background CPUs (slaves) and hardware processing modules to process the target task, a first target memory region is allocated to the target background CPU (slave) based on software memory requirements, and a second target memory region is allocated to the target solid-state drive based on hardware memory requirements.

[0070] S34. The software tasks are assigned to the target background CPU through a unified software interface, and the hardware tasks are assigned to the hardware processing module located inside the target solid-state drive through a unified hardware interface.

[0071] Furthermore, software tasks are assigned to at least one idle background CPU (slave) through a unified software interface, and hardware tasks are assigned to the hardware processing module inside the solid-state drive through a unified hardware interface. A preset data structure is used to determine whether there is an idle channel in the hardware processing module. If there is, the hardware task is assigned to the idle channel so that the solid-state drive can process the target task.

[0072] Each background CPU maintains a first-in-first-out (FIFO) queue for tasks waiting to run and several other first-in-first-out (FIFO) queues for completed tasks, determined by the type of software task, awaiting the results from the foreground CPU. Each type of hardware processing module can execute multiple hardware tasks in parallel, with each executable hardware task corresponding to a channel. Each type of hardware processing module maintains a data structure indicating whether each of its channels is idle, and supports traversing the next idle channel within a constant time.

[0073] After sending the software task to the target background CPU (slave) and the hardware task to the hardware processing module, the system receives the task reception results returned by the target background CPU (slave) and the target solid-state drive. If the resources of the target background CPU or the target solid-state drive are insufficient, the task reception result is considered a failure. The software tasks that failed to be received by the target background CPU are run in the foreground CPU (master), and the hardware tasks that failed to be received by the target solid-state drive are cached until the resources of the target solid-state drive are sufficient, at which point the hardware tasks are processed again.

[0074] Optionally, if the target background CPU (slave) has sufficient resources, the task reception result is successful; the task running status of the software task is received from the target background CPU (slave); if the task running status is successful, the result of task processing completion is returned by the target background CPU (slave).

[0075] The resource scheduling method provided in this invention involves selecting any one CPU as the foreground CPU and the others as background CPUs in a target system with multiple CPUs; obtaining the target task to be processed; performing software and hardware task parsing on the target task to obtain the software task and hardware task to be processed; and performing software and hardware resource scheduling on the software task and hardware task through a unified software interface and / or hardware interface to process the target task. This method supports unified scheduling and management of different hardware resources within an SSD when the FTL software has multiple CPU cores, allowing FTL developers to use a unified interface to call different types of internal hardware resources.

[0076] Figure 4 A schematic diagram of a resource scheduling device provided in an embodiment of the present invention specifically includes:

[0077] Setting module 401 is used to select any CPU as the foreground CPU and the other CPUs as background CPUs in a target system with multiple CPUs.

[0078] Module 402 is used to acquire the target task to be processed;

[0079] The parsing module 403 is used to perform software and hardware task parsing on the target task to obtain the software task and hardware task to be processed.

[0080] The scheduling module 404 is used to schedule software and hardware resources for the software tasks and hardware tasks through a unified software interface and / or hardware interface in order to process the target task.

[0081] In one possible implementation, the setting module 401 is further configured to determine the running status of each background CPU based on a first first-in-first-out queue of waiting tasks maintained by each background CPU and a second first-in-first-out queue of multiple tasks that have completed execution and are waiting for the foreground CPU to query the running results, wherein the running status refers to the number of software tasks waiting to be executed in the task queue of each background CPU; and to determine whether there is an idle channel in the hardware processing module based on a preset data structure.

[0082] In one possible implementation, the scheduling module 404 is further configured to allocate the software task to at least one background CPU through a unified software interface, and allocate the hardware task to a hardware processing module through a unified hardware interface, so that the hardware processing module performs hardware resource scheduling on the target task.

[0083] In one possible implementation, the scheduling module 404 is further configured to set corresponding software memory requirements and hardware memory requirements for the software task and hardware task respectively; based on the memory requirements, select a target background CPU and a target solid-state drive that meet preset conditions from other CPUs; allocate the software task to the target background CPU through a unified software interface, and allocate the hardware task to the hardware processing module located inside the target solid-state drive through a unified hardware interface.

[0084] In one possible implementation, the scheduling module 404 is further configured to allocate a first target memory region to the target background CPU based on the software memory requirements, and to allocate a second target memory region to the target solid-state drive based on the hardware memory requirements.

[0085] In one possible implementation, the scheduling module 404 is further configured to receive task reception results returned by the target background CPU and the hardware processing module; if the resources of the target background CPU or the hardware processing module are insufficient, the task reception result is a failure; the software tasks that failed to be received by the target background CPU are run in the foreground CPU, and the hardware tasks that failed to be received by the hardware processing module are cached until the resources of the hardware processing module are sufficient, and then the hardware tasks are processed again.

[0086] In one possible implementation, the scheduling module 404 is further configured to: if the target background CPU has sufficient resources, then the task reception result is successful; receive the task reception result of the target background CPU for the software task; if the task reception result is successful, then receive the result of task processing completion returned by the target background CPU; if the task reception result is unsuccessful, then run the software task with the unsuccessful task reception result in the foreground CPU.

[0087] The resource scheduling device provided in this embodiment can be as follows: Figure 4 The resource scheduling device shown can perform the following: Figure 2-3 All steps of the resource scheduling method are then implemented to achieve... Figure 2-3 For details on the technical effects of the resource scheduling method shown, please refer to [link / reference]. Figure 2-3 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0088] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Figure 5 The illustrated electronic device 500 includes at least one processor 501, a memory 502, at least one network interface 504, and other user interfaces 503. The various components in the electronic device 500 are coupled together via a bus system 505. It is understood that the bus system 505 is used to implement communication between these components. In addition to a data bus, the bus system 505 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 5 The general designated all buses as Bus System 505.

[0089] The user interface 503 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0090] It is understood that the memory 502 in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 502 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0091] In some implementations, memory 502 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 5021 and application program 5022.

[0092] The operating system 5021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 5022 includes various applications, such as a media player and a browser, used to implement various application functions. The program implementing the method of this embodiment can be included in the application program 5022.

[0093] In this embodiment of the invention, by calling the program or instructions stored in memory 502, specifically the program or instructions stored in application program 5022, processor 501 executes the method steps provided in each method embodiment, including, for example:

[0094] In a target system with multiple CPUs, select any CPU as the foreground CPU and the others as background CPUs; obtain the target task to be processed; perform software and hardware task parsing on the target task to obtain the software task and hardware task to be processed; and perform software and hardware resource scheduling on the software task and hardware task through a unified software interface and / or hardware interface to process the target task.

[0095] In one possible implementation, the software task is assigned to at least one background CPU through a unified software interface, and the hardware task is assigned to a hardware processing module through a unified hardware interface, so that the hardware processing module performs hardware resource scheduling for the target task.

[0096] In one possible implementation, corresponding software memory requirements and hardware memory requirements are set for the software task and hardware task, respectively; based on the memory requirements, a target background CPU and a target solid-state drive that meet preset conditions are selected from other CPUs; the software task is assigned to the target background CPU through a unified software interface, and the hardware task is assigned to the hardware processing module located inside the target solid-state drive through a unified hardware interface.

[0097] In one possible implementation, a first target memory region is allocated to the target background CPU based on the software memory requirements, and a second target memory region is allocated to the target solid-state drive based on the hardware memory requirements.

[0098] In one possible implementation, the task reception results returned by the target background CPU and the hardware processing module are received; if the resources of the target background CPU or the hardware processing module are insufficient, the task reception result is considered a failure; the software tasks that failed to be received by the target background CPU are run in the foreground CPU, and the hardware tasks that failed to be received by the hardware processing module are cached until the resources of the hardware processing module are sufficient, and then the hardware tasks are processed again.

[0099] In one possible implementation, if the target background CPU has sufficient resources, the task reception result is successful; the task reception result of the target background CPU for the software task is received; if the task reception result is successful, the result of task processing completion returned by the target background CPU is received; if the task reception result is unsuccessful, the software task with the unsuccessful task reception result is run in the foreground CPU.

[0100] In one possible implementation, the running status of each background CPU is determined based on a first first-in-first-out queue of one waiting task maintained by each background CPU and a second first-in-first-out queue of multiple tasks that have completed execution and are waiting for the foreground CPU to query the execution results. The running status refers to the number of software tasks waiting to be executed in the task queue of each background CPU.

[0101] The system determines whether there are idle channels in the hardware processing module based on a preset data structure.

[0102] The methods disclosed in the above embodiments of the present invention can be applied to or implemented by processor 501. Processor 501 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 501 or by instructions in the form of software. The processor 501 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of the present invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 502. Processor 501 reads the information in memory 502 and, in conjunction with its hardware, completes the steps of the above method.

[0103] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0104] For software implementation, the techniques described herein can be implemented by units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0105] The electronic device provided in this embodiment may be as follows: Figure 5 The electronic device shown can perform the following: Figure 2-3 All steps of the resource scheduling method are then implemented to achieve... Figure 2-3 For details on the technical effects of the resource scheduling method shown, please refer to [link / reference]. Figure 2-3 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0106] This invention also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; the memory may also include combinations of the above types of memory.

[0107] When one or more programs in the storage medium can be executed by one or more processors, the resource scheduling method described above for execution on the electronic device side can be implemented.

[0108] The processor is used to execute a resource scheduler stored in memory to implement the following steps of a resource scheduling method executed on the electronic device side:

[0109] In a target system with multiple CPUs, select any CPU as the foreground CPU and the others as background CPUs; obtain the target task to be processed; perform software and hardware task parsing on the target task to obtain the software task and hardware task to be processed; and perform software and hardware resource scheduling on the software task and hardware task through a unified software interface and / or hardware interface to process the target task.

[0110] In one possible implementation, the software task is assigned to at least one background CPU through a unified software interface, and the hardware task is assigned to a hardware processing module through a unified hardware interface, so that the hardware processing module performs hardware resource scheduling for the target task.

[0111] In one possible implementation, corresponding software memory requirements and hardware memory requirements are set for the software task and hardware task, respectively; based on the memory requirements, a target background CPU and a target solid-state drive that meet preset conditions are selected from other CPUs; the software task is assigned to the target background CPU through a unified software interface, and the hardware task is assigned to the hardware processing module located inside the target solid-state drive through a unified hardware interface.

[0112] In one possible implementation, a first target memory region is allocated to the target background CPU based on the software memory requirements, and a second target memory region is allocated to the target solid-state drive based on the hardware memory requirements.

[0113] In one possible implementation, the task reception results returned by the target background CPU and the hardware processing module are received; if the resources of the target background CPU or the hardware processing module are insufficient, the task reception result is considered a failure; the software tasks that failed to be received by the target background CPU are run in the foreground CPU, and the hardware tasks that failed to be received by the hardware processing module are cached until the resources of the hardware processing module are sufficient, and then the hardware tasks are processed again.

[0114] In one possible implementation, if the target background CPU has sufficient resources, the task reception result is successful; the task reception result of the target background CPU for the software task is received; if the task reception result is successful, the result of task processing completion returned by the target background CPU is received; if the task reception result is unsuccessful, the software task with the unsuccessful task reception result is run in the foreground CPU.

[0115] In one possible implementation, the running status of each background CPU is determined based on a first first-in-first-out queue of one waiting task maintained by each background CPU and a second first-in-first-out queue of multiple tasks that have completed execution and are waiting for the foreground CPU to query the execution results. The running status refers to the number of software tasks waiting to be executed in the task queue of each background CPU.

[0116] The system determines whether there are idle channels in the hardware processing module based on a preset data structure.

[0117] Those skilled in the art will further 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, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. 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 implementations should not be considered beyond the scope of this invention.

[0118] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0119] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A resource scheduling method, characterized in that, include: In a target system with multiple CPUs, select any one CPU as the foreground CPU and the other CPUs as background CPUs. Obtain the target task to be processed; The target task is parsed to obtain the software task and hardware task to be processed. The software and hardware tasks are processed by scheduling software and hardware resources through a unified software and hardware interface to handle the target task. The process of scheduling software and hardware resources through a unified software and hardware interface to process the target task includes: The software task is assigned to at least one background CPU through a unified software interface, and the hardware task is assigned to a hardware processing module through a unified hardware interface, so that the hardware processing module can perform hardware resource scheduling for the target task. The step of allocating the software task to at least one background CPU through a unified software interface and allocating the hardware task to a hardware processing module through a unified hardware interface, so that the hardware processing module performs hardware resource scheduling for the target task, includes: Set corresponding software memory requirements and hardware memory requirements for the software tasks and hardware tasks respectively; Based on the memory requirements, select at least one target backend CPU and one target solid-state drive from among the other CPUs that meet the preset conditions; The software tasks are assigned to the target background CPU through a unified software interface, and the hardware tasks are assigned to the hardware processing module located inside the target solid-state drive through a unified hardware interface, thereby enabling the FTL software to uniformly schedule and manage different hardware resources inside the SSD when there are multiple CPU cores.

2. The method according to claim 1, characterized in that, The method further includes: Based on the software memory requirements, a first target memory region is allocated to the target background CPU, and based on the hardware memory requirements, a second target memory region is allocated to the target solid-state drive.

3. The method according to claim 1, characterized in that, The step of allocating the software tasks to the target backend CPU through a unified software interface and allocating the hardware tasks to the hardware processing module located inside the target solid-state drive through a unified hardware interface includes: Receive the task reception result returned by the target backend CPU and the hardware processing module; If the target background CPU or the hardware processing module has insufficient resources, the task reception result will be a failure. The software tasks that fail to be received by the target background CPU are run in the foreground CPU, and the hardware tasks that fail to be received by the hardware processing module are cached until the hardware processing module has sufficient resources to continue processing the hardware tasks.

4. The method according to claim 3, characterized in that, The method further includes: If the target background CPU has sufficient resources, the task reception result is successful; Receive the task reception result of the target background CPU for the software task; If the task reception result is successful, then receive the result that the task processing is completed returned by the target background CPU; If the task reception result is a failure, then the software task with the failed task reception result will be run in the foreground CPU.

5. The method according to claim 1, characterized in that, The method further includes: Based on a first first-in-first-out queue of one waiting task maintained by each background CPU and a second first-in-first-out queue of multiple tasks that have completed execution and are waiting for the foreground CPU to query the execution results, the running status of each background CPU is determined, wherein the running status refers to the number of software tasks waiting to be executed in the task queue of each background CPU. The system determines whether there are idle channels in the hardware processing module based on a preset data structure.

6. A resource scheduling device, characterized in that, include: The configuration module is used to select any CPU as the foreground CPU and the other CPUs as background CPUs in a target system with multiple CPUs. The acquisition module is used to acquire the target task to be processed; The parsing module is used to parse the target task into software and hardware tasks to obtain the software and hardware tasks to be processed. The scheduling module is used to schedule software and hardware resources for the software tasks and hardware tasks through a unified software interface and hardware interface in order to process the target task. The scheduling module is also used for: The software task is assigned to at least one background CPU through a unified software interface, and the hardware task is assigned to a hardware processing module through a unified hardware interface, so that the hardware processing module can perform hardware resource scheduling for the target task. The scheduling module is also used for: Set corresponding software memory requirements and hardware memory requirements for the software tasks and hardware tasks respectively; Based on the memory requirements, select at least one target backend CPU and one target solid-state drive from among the other CPUs that meet the preset conditions; The software tasks are assigned to the target background CPU through a unified software interface, and the hardware tasks are assigned to the hardware processing module located inside the target solid-state drive through a unified hardware interface, thereby enabling the FTL software to uniformly schedule and manage different hardware resources inside the SSD when there are multiple CPU cores.

7. An electronic device, characterized in that, include: A processor and a memory, the processor being configured to execute a resource scheduling program stored in the memory to implement the resource scheduling method according to any one of claims 1 to 5.

8. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the resource scheduling method according to any one of claims 1 to 5.

Images