Host, information processing method, electronic system and readable storage medium

Abstract

The embodiment of the invention discloses a host, an information processing method, an electronic system and a readable storage medium. Wherein the host comprises a processor; the processor comprises a first central processing unit (CPU) core bound with a first thread and a second CPU core bound with a second thread, wherein the first CPU core is configured to, in response to control of the first thread, transmit an input / output (I / O) request to a storage device coupled to the host; and the second CPU core is configured to respond to the control of the second thread and receive feedback information which is sent by the storage equipment and is related to the I / O request.

Description

Host, information processing method, electronic system and readable storage medium Technical Field

[0001] The present disclosure relates to the field of storage technology, and in particular to a host, an information processing method, an electronic system, and a readable storage medium. Background Art

[0002] Currently, electronic systems typically include a host computer and a storage device containing a memory system. The host's central processing unit (CPU) core can send data to the storage device or receive feedback from the storage device. Currently, the data transmission method used by the CPU core requires a large number of locks, resulting in a large lock overhead for the electronic system. Furthermore, the feedback receiving method requires interrupt context switching, which takes a considerable amount of time to save and restore data. This results in a relatively large time overhead for the electronic system, resulting in poor performance of the host's access to the storage device.

[0003] Summary of the Invention

[0004] In view of this, the present disclosure provides a host, an information processing method, an electronic system, and a readable storage medium.

[0005] In a first aspect, the present disclosure provides a host comprising: a first central processing unit (CPU) core bound to a first thread and a second CPU core bound to a second thread; wherein,

[0006] The first CPU core is configured to: send an input / output (I / O) request to a storage device coupled to the host in response to control of the first thread;

[0007] The second CPU core is configured to: receive feedback information related to the I / O request sent by the storage device in response to control of the second thread.

[0008] In the above solution, the processor further comprises: a device interface; the device interface comprises: a host controller interface; the host controller interface comprises an interrupt register;

[0009] The second CPU core is further configured to: poll the interrupt register in response to the control of the second thread to receive the feedback information.

[0010] In the above scheme, the second CPU core is specifically configured to: in response to the control of the second thread, regularly access the interrupt register at a preset time interval to determine whether the feedback information is received in the interrupt register; if the feedback information is received, obtain the feedback information from the interrupt register.

[0011] In the above solution, wherein, the host further comprises a memory; the memory is configured to store a request command queue; the request command queue comprises: one or more request commands; the one or more request commands correspond to one or more I / O requests;

[0012] The first CPU core is configured to: in response to control of the first thread, obtain the one or more request commands from the request command queue and send the one or more request commands to the storage device.

[0013] In the above solution, wherein, the host controller interface further comprises: a doorbell register;

[0014] The second CPU core is further configured to: access the doorbell register to determine the I / O request corresponding to the feedback information.

[0015] In the above solution, the first CPU core is further configured to: access the doorbell register to allocate a required transmission channel for the I / O request in the ready state.

[0016] In the above solution, the access mode of the doorbell register is a locked access mode, wherein the locked access mode includes that the doorbell register is only accessed by the first CPU core or the second CPU core at the same time.

[0017] In the above solution, the I / O request is generated by an application running on the processor, and the I / O request is converted by a device driver running on the processor into one or more request commands in a format supported by the storage device.

[0018] In the above solution, the device interface further comprises: a joint protocol circuit and an M-physical interface circuit, wherein;

[0019] The joint protocol circuit and the M-physical interface circuit are connected to the host controller interface and are configured to: send a request command to the storage device or receive the feedback information sent by the storage device, wherein the request command is generated based on the I / O request.

[0020] In the above solution, the storage device is a Universal Flash Storage (UFS) device.

[0021] In the above solution, the operating system running in the host is a Linux operating system.

[0022] In the above solution, the processor includes multiple CPU cores, wherein the first CPU core is any one of the multiple CPU cores; and the second CPU core is any one of the multiple CPU cores except the first CPU core.

[0023] In a second aspect, the present disclosure further provides a host information processing method, comprising:

[0024] Binding a first thread to a first central processing unit (CPU) core included in the host;

[0025] Binding the second thread to a second CPU core included in the host;

[0026] When the first thread is running, the first CPU core is controlled to send an input / output (I / O) request to a storage device coupled to the host; when the second thread is running, the second CPU core is controlled to receive feedback information related to the I / O request sent by the storage device.

[0027] In the above solution, when the second thread is running, controlling the second CPU core to receive feedback information related to the I / O request sent by the storage device further includes:

[0028] When the second thread is running, the second CPU core is controlled to poll the interrupt register included in the host to receive the feedback information.

[0029] In the above scheme, the controlling of the second CPU core to poll the interrupt register contained in the host to receive the feedback information includes: regularly accessing the interrupt register at a preset time interval to determine whether the feedback information is received in the interrupt register; if the feedback information is received, obtaining the feedback information from the interrupt register.

[0030] In the above solution, wherein, when the first thread is running, controlling the first CPU core to send an input / output (I / O) request to a storage device coupled to the host includes:

[0031] When the first thread is running, controlling the first CPU core to obtain one or more request commands from a request command queue stored in a memory of the host, and sending the one or more request commands to the storage device;

[0032] The one or more request commands correspond to one or more I / O requests.

[0033] In the above solution, the method further comprises:

[0034] When the first thread is running, controlling the first CPU core to access the doorbell register included in the host to allocate a required transmission channel for the I / O request in the ready state;

[0035] When the second thread is running, the second CPU core is controlled to access the doorbell register to determine the I / O request corresponding to the feedback information.

[0036] In the above solution, the access mode of the doorbell register is a locked access mode, wherein the locked access mode includes that the doorbell register is only accessed by the first CPU core or the second CPU core at the same time.

[0037] In a third aspect, the present disclosure relates to an electronic system, comprising:

[0038] A host; the host includes a processor; the processor is configured to: bind a first thread to a first central processing unit (CPU) core included in the processor; and bind a second thread to a second CPU core included in the processor; run the first thread, and control the first CPU core to send an input / output (I / O) request to the storage device;

[0039] and a storage device coupled to the host; the storage device being configured to: receive and process the I / O request; generate feedback information related to the I / O request; and send the feedback information to the host;

[0040] The processor is further configured to: run the second thread and control the second CPU core to receive the feedback information sent by the storage device.

[0041] In the above solution, the processor further comprises: a device interface; the device interface comprises a host controller interface; the host controller interface comprises an interrupt register;

[0042] The second CPU core is further configured to: in response to control of the second thread, periodically send a first access command to the interrupt register at a preset time interval;

[0043] The interrupt register is configured to: in response to the first access command, send the feedback information to the second CPU core when receiving the feedback information sent by the storage device.

[0044] In the above solution, the host further includes a memory; the memory is configured to store a request command queue; the request command queue includes one or more request commands; the one or more request commands correspond to one or more I / O requests;

[0045] The first CPU core is further configured to: send a second access command to the memory in response to control of the first thread;

[0046] The memory is configured to: in response to the second access command, obtain the one or more request commands from the request command queue, and send the one or more request commands to the first CPU core;

[0047] The first CPU core is further configured to: send the one or more request commands to the storage device.

[0048] In a fourth aspect, the present disclosure further provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements any of the above-described methods when executed by a processor.

[0049] The embodiments of the present disclosure provide a host, an information processing method, an electronic system and a readable storage medium. The host includes: a first central processing unit (CPU) core bound to a first thread and a second CPU core bound to a second thread; the first CPU core is configured to: send an input / output (I / O) request to a storage device coupled to the host in response to the control of the first thread; the second CPU core is configured to: receive feedback information related to the I / O request sent by the storage device in response to the control of the second thread. In the host provided in the embodiments of the present disclosure, by binding the first thread to the first CPU core and the second thread to the second CPU core, two dedicated CPU cores are used to process I / O requests between the host and the storage device, thereby reducing a large amount of lock overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In the accompanying drawings, which are not necessarily drawn to scale, like reference numerals may describe similar components in different views. Like numerals with different letter suffixes may represent different instances of similar components. The accompanying drawings generally illustrate various embodiments discussed in this document by way of example and not limitation.

[0051] FIG1 illustrates a system block diagram of an exemplary electronic device having a memory system;

[0052] FIG2 shows an example diagram of a structure of a host in the system shown in FIG1 ;

[0053] FIG3 is a schematic structural diagram of a memory controller included in the memory system of the system shown in FIG1 ;

[0054] FIG4 is a schematic diagram showing a structure of a memory device included in the memory system;

[0055] FIG5 is a schematic diagram showing a process flow of a host sending an I / O request to a storage device and receiving feedback from the storage device regarding the I / O request;

[0056] FIG6 shows a structural diagram 1 of a host provided by an embodiment of the present disclosure;

[0057] FIG7 shows a schematic diagram of the logical structure of a Linux-based operating system provided in an embodiment of the present disclosure;

[0058] FIG8 is a schematic diagram showing the structure of a Linux kernel provided in an embodiment of the present disclosure;

[0059] FIG9 is a schematic diagram showing a mapping relationship between user threads and kernel threads according to an embodiment of the present disclosure;

[0060] FIG10 is a schematic diagram illustrating scheduling between processes when a user thread is not mapped to a kernel thread according to an embodiment of the present disclosure;

[0061] FIG11 is a schematic diagram illustrating scheduling between threads when a user thread is mapped to a kernel thread according to an embodiment of the present disclosure;

[0062] FIG12 is a schematic diagram showing the scheduling of threads in the same process running on the same CPU core provided in an embodiment of the present disclosure;

[0063] FIG13 is a schematic diagram showing the scheduling of different processes provided in an embodiment of the present disclosure when they run on different CPU cores;

[0064] FIG14 is a schematic diagram showing the scheduling of threads in the same process running on different CPU cores provided in an embodiment of the present disclosure;

[0065] FIG15 is a schematic diagram showing the structure of a Linux-based storage system provided in an embodiment of the present disclosure;

[0066] 16-20 illustrate the interaction relationship between various layers in a Linux-based storage system provided in an embodiment of the present disclosure;

[0067] FIG21 shows a second structural diagram of a host provided in an embodiment of the present disclosure;

[0068] FIG22 shows a third structural diagram of a host provided in an embodiment of the present disclosure;

[0069] FIG23 shows a fourth structural diagram of a host provided in an embodiment of the present disclosure;

[0070] FIG24 is a schematic diagram showing a process flow of a host sending an I / O request to a storage device and receiving feedback information according to an embodiment of the present disclosure;

[0071] FIG25 is a schematic flow chart showing a method for processing information by a host provided in an embodiment of the present disclosure;

[0072] FIG26 shows a schematic structural diagram of an electronic system provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0073] The following describes various embodiments of the present disclosure in more detail with reference to the accompanying drawings. Other embodiments that can be used as variations of any disclosed embodiment can be formed by configuring or arranging the elements and features in the embodiments of the present disclosure in different ways. Therefore, the embodiments of the present disclosure are not limited to the embodiments set forth herein. On the contrary, the described embodiments are provided so that the embodiments of the present disclosure are thorough and complete, and the scope of the embodiments of the present disclosure is fully conveyed to those skilled in the art of the technical field to which the embodiments of the present disclosure belong. It should be noted that references to "embodiment", "another embodiment" and the like do not necessarily represent only one embodiment, and different references to any such phrases are not necessarily for the same embodiment. It should be understood that although the terms "first", "second", "third" and the like may be used herein to identify various elements, these elements are not limited by these terms. These terms are used to distinguish one element from another element with the same or similar name. Therefore, without departing from the spirit and scope of the embodiments of the present disclosure, the first element in one embodiment may also be referred to as the second or third element in another embodiment.

[0074] The accompanying drawings are not necessarily drawn to scale, and in some cases, the scale may be exaggerated to clearly illustrate the features of the embodiments. When an element is referred to as being connected or coupled to another element, it should be understood that the former may be directly connected or coupled to the latter, or may be electrically connected or coupled to the latter via one or more intermediate elements therebetween. In addition, it should be understood that when an element is referred to as being "between" two elements, the element may be the only element between the two elements, or one or more intermediate elements may be present.

[0075] The terms used in this article are only for the purpose of describing specific embodiments and are not intended to limit the present disclosure. As used herein, the singular form is intended to include the plural form, unless the context clearly indicates otherwise. Unless otherwise specified or can be clearly understood from the context to be singular, the articles "one" and / or "an" used in the embodiments of the present disclosure and the appended claims should be collectively interpreted as meaning "one or more". It should be further understood that the terms "include", "include", "include" and "include" used in the embodiments of the present disclosure specify the presence of the elements and do not exclude the presence or addition of one or more other elements. The term "and / or" used in the embodiments of the present disclosure includes any and all combinations of one or more associated listed items. Unless otherwise defined, all terms including technology and science used in the embodiments of the present disclosure have the same meaning as those of ordinary skill in the art to which the present disclosure belongs in view of the embodiments of the present disclosure. It should be further understood that, unless the embodiments of the present disclosure are clearly defined, terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the embodiments of the present disclosure and the related art, and should not be interpreted in an idealized or overly formal manner.

[0076] In the following description, many specific details are set forth to provide a thorough understanding of the present disclosure, and the present disclosure can be practiced without some or all of these specific details. In other cases, well-known processing structures and / or processes are not described in detail to avoid unnecessarily obscuring the present disclosure. It should also be understood that in some cases, unless otherwise specified, it will be apparent to those skilled in the relevant art that features or elements described with respect to one embodiment may be used alone or in combination with other features or elements of another embodiment. Hereinafter, various embodiments of the present disclosure are described in detail with reference to the accompanying drawings. The following description focuses on details to facilitate understanding of the embodiments of the present disclosure. Well-known technical details may be omitted to avoid obscuring the features and aspects of the embodiments of the present disclosure.

[0077] The embodiments of the present disclosure are further described in detail below with reference to the accompanying drawings and specific embodiments.

[0078] FIG1 shows a system block diagram of an exemplary electronic device having a storage system. In FIG1 , the electronic device may be a mobile phone, a desktop computer, a laptop computer, a tablet computer, a vehicle computer, a game console, a printer, a positioning device, a wearable electronic device, a smart sensor, a virtual reality (VR) device, an augmented reality (AR) device, or any other suitable electronic device having a memory system therein. As shown in FIG1 , system 100 is a system in an electronic device, which may include a host 108 and a memory system 102, the memory system being contained in a storage device; wherein,

[0079] Specifically, as shown in FIG2 , the host 108 may include a first processor 201 such as a central processing unit (CPU) or a system on chip (SoC), wherein the system on chip may be, for example, an application processor (AP). The first processor 201 may include a multi-core processor 2011 and a peripheral interface (or device interface) 2012, wherein the multi-core processor 2011 may include multiple CPU cores (CPU core 2011-1 to CPU core 2011-N, wherein N is an integer greater than 1), wherein each CPU core may include a logic circuit (or module) with logical operation and control capabilities. The peripheral interface 2012 is a channel for communicating with the memory system to enable the host to read data from the memory system or the host to write data to the memory system.

[0080] Host 108 also includes at least one operating system (OS) that can generally manage and control functions and operations executed within host 108. The OS enables interoperability between host 108, which is coupled to memory system 102, and users who require and use memory system 102. The OS can support functions and operations corresponding to user requests. For example, and not limitation, depending on whether host 102 is a mobile host, the OS can be categorized as a general-purpose operating system (OS) or a mobile operating system (MOOS). General-purpose operating systems can include personal operating systems (POSs) and enterprise operating systems (OOSs). Personal operating systems can include operating systems such as Windows and Chrome that are generally used to support services. Enterprise operating systems can include operating systems specifically designed to ensure and support high performance, such as Windows Server, Linux, and Unix. A mobile operating system can refer to an operating system that provides services or functions specifically for mobility (e.g., power saving functions). Generally, mobile operating systems can include operating systems such as Android, I / OS, and Windows Mobile. In some embodiments, host 108 can include multiple OSs; accordingly, host 108 can run multiple operating systems associated with memory system 102. In other embodiments, the host 108 converts the user's request into one or more commands and transmits the one or more commands to the memory system 102, so that the memory system 102 performs operations associated with the one or more commands. It should be understood that the OS is used in the CPU core. For example, a mobile electronic device including a UFS can be used under the Android platform, and the CPU core included therein uses Linux.

[0081] The memory system 102 can operate or perform specific functions or perform various internal operations in response to a request from the host 108. In some embodiments, the memory system 102 can store data accessed by the host 108. The memory system 102 can be used as a primary memory system or an auxiliary memory system of the host 108. The memory system 102 and the host 108 can be electrically connected and communicated according to corresponding protocols. The memory system 102 can be implemented and packaged into different types of terminal electronic products, such as, but not limited to: solid state drive (SSD), multimedia card (MMC), embedded MMC (eMMC), reduced size MMC (RSMMC), micro MMC, secure digital (SD) card, mini SD, micro SD, universal serial bus (USB) storage device, universal flash memory (UFS) device, compact flash (CF) card, smart media (SM) card and memory stick, etc.

[0082] In some embodiments, the memory system 102 may also be configured as part of, for example, a computer, an ultra-mobile PC (UMPC), a workstation, a netbook, a personal digital assistant (PDA), a portable computer, a web tablet, a tablet computer, a wireless phone, a mobile phone, a smart phone, an e-book, a portable multimedia player (PMP), a portable game console, a navigation system, a black box, a digital camera, a digital multimedia broadcasting (DMB) player, a three-dimensional (3D) television, a smart TV, a digital audio recorder, a digital audio player, a digital photo recorder, a digital photo player, a digital video recorder, a digital video player, a storage device configured in a data center, a device capable of transmitting and receiving information in a wireless environment, one of various electronic devices configured in a home network, one of various electronic devices configured in a computer network, one of various electronic devices configured in a telematics network, a radio frequency identification (RFID) device, or one of various components configured in a computing system.

[0083] Returning to FIG. 1 , the memory system 102 may include one or more memory devices 104 and a memory controller 106. The memory controller 106 may respond to requests from the host 108 and thereby control the memory devices 104. For example, the memory controller 106 may read data from the memory devices 104 and transmit the read data to the host 108. The memory controller 106 may also receive data to be stored from the host 108 and store the data to be stored in the memory devices 104. In other words, the memory controller 106 is capable of controlling write (or program) operations, read operations, erase operations, background operations, and the like of the memory devices 104.

[0084] Specifically, as shown in FIG3 , the memory controller 106 may include a front-end interface 301, a back-end interface 302, a processor 303, and a memory 304. The components 301, 302, 303, and 304 in the memory controller 106 may share transmission signals within the memory controller 106 via an internal bus. In some embodiments, the front-end interface 301 may interface the host 108 with the memory system 102 in response to a protocol of the host 108, and the front-end interface 301 may exchange transmission commands and data operations between the host 108 and the memory system 102. The front-end interface 301 may process commands and data sent by the host 108 and may include at least one of the following: a universal serial bus (USB), a multimedia card (MMC), a peripheral component interconnect express (PCI-e or PCIe), a small computer system interface (SCSI), serial SCSI (SAS), serial advanced technology attachment (SATA), parallel advanced technology attachment (PATA), a small computer system interface (SCSI), an enhanced small disk interface (ESDI), and integrated drive electronics (IDE). In some embodiments, the front-end interface 301 is a component used by the memory system 102 to exchange data with the host 108 and may be implemented by firmware called a host interface layer (HIL).

[0085] The backend interface 302 may be an interface for commands and data transmitted between the memory controller 106 and the memory device 104, allowing the memory controller 106 to control the memory device 104 in response to a request transmitted from the host 108. The backend interface 302 may generate control signals for controlling the memory device 104. In some embodiments, if the memory device 104 is a NAND flash memory, the backend interface 302 may write data to the memory device 104 or read data from the memory device 104 under the control of the second processor 303. The backend interface 302 may process commands and data between the memory controller 106 and the memory device 104, for example, operations of a NAND flash memory interface, and in particular operations between the memory controller 106 and the memory device 104. According to an embodiment, the backend interface 302 may be implemented as a component for exchanging data with the memory device 104 via firmware referred to as a flash interface layer (FIL).

[0086] The second processor 303 can be implemented as a microprocessor or a central processing unit (CPU). The memory system 102 may include one or more second processors 303. The second processor 303 can control all operations of the memory system 102. As an example and not a limitation, the second processor 303 can control programming operations or read operations of the memory device 104 in response to a write request or a read request from the host 108. According to an embodiment, the second processor 303 can use or run firmware to control all operations of the memory system 102. In this disclosure, the firmware can be referred to as a flash translation layer (FTL). The FTL can perform operations as an interface between the host 108 and the memory device 104. The host 108 can transmit requests related to write operations and read operations to the memory device 104 through the FTL. For example, when executing an operation requested by the host 108 in the memory device 104, the memory controller 106 uses the second processor 303. The second processor 303 coupled to the memory device 104 can process instructions or commands related to commands from the host 108. The memory controller 106 may perform foreground operations such as command operations corresponding to commands input from the host 108, for example, a program operation corresponding to a write command, a read operation corresponding to a read command, an erase / discard operation corresponding to an erase / discard command, and a parameter setting operation corresponding to a set parameter command or a set feature command having a set command.

[0087] For another example, the memory controller 106 may perform background operations on the memory device 104 via the second processor 303. By way of example and not limitation, these background operations may include garbage collection (GC) operations, wear leveling (WL) operations, map cleanup operations, and bad block management operations for checking or searching for bad blocks. The garbage collection operation may include an operation for copying and processing data stored in a memory block in the memory device 104 (such as the memory device shown in FIG4 ) to another memory block. The wear leveling operation may include an operation for exchanging and processing stored data between the memory blocks MEMORY BLOCK<0, 1, 2, ...> of the memory device 104. The map cleanup operation may include an operation for storing map data stored in the memory controller 106 in the memory blocks MEMORYBLOCK<0, 1, 2, ...> of the memory device 104. The bad block management operation may include an operation for checking and processing bad blocks in the memory blocks MEMORY BLOCK<0, 1, 2, ...> of the memory device 104. The memory controller 106 may respond to operations for accessing the memory blocks MEMORY BLOCK<0, 1, 2, ...> of the memory device 104, wherein the operations for accessing the memory blocks MEMORY BLOCK<0, 1, 2, ...> of the memory device 104 may include foreground operations or background operations performed on the memory blocks MEMORY BLOCK<0, 1, 2, ...> of the memory device 104.

[0088] The memory 304 may be a working memory of the memory controller 106 and is configured to store data for driving the memory controller 106. More specifically, when the memory controller 106 controls the memory device 104 in response to a request from the host 108, the memory 304 may store firmware driven by the second processor 303 and data required to drive the firmware (e.g., metadata). The memory 304 may also be a buffer memory of the memory controller 106 and is configured to temporarily store write data transferred from the host 108 to the memory device 104 and read data transferred from the memory device 104 to the host 108. The memory 304 may include a program memory for storing write data and read data, a data memory, a write buffer / cache, a read buffer / cache, a data buffer / cache, and a mapping buffer / cache. The memory 304 may be implemented using a volatile memory. The memory 304 may be implemented using static random access memory (SRAM), dynamic random access memory (DRAM), or both.

[0089] 3 shows that memory 304 is included in memory controller 106, the present disclosure is not limited thereto. In an embodiment, memory 304 may be included outside memory controller 106, and memory controller 106 may input and output data to memory 304 through a separate memory interface (not shown).

[0090] Referring back to FIG. 1 , the memory device 104 may be a non-volatile memory device that retains data stored therein even when power is not supplied. The memory device 104 may store data provided from the host 108 through a write operation; the memory device 104 may also provide the stored data to the host 108 through a read operation. In embodiments of the present disclosure, the memory device 104 may be any of the disclosed memories, such as volatile memory devices such as dynamic random access memory (DRAM) and static RAM (SRAM), or non-volatile memory devices such as read-only memory (ROM), mask ROM (MROM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), ferroelectric RAM (FRAM), phase change RAM (PRAM), magnetoresistive RAM (MRAM), resistive RAM (RRAM or ReRAM), and flash memory (e.g., three-dimensional NAND flash memory).

[0091] As shown in Figure 4, the memory device 104 may include multiple memory blocks MEMORY BLOCK<0, 1, 2, ...>. Each memory block may include multiple pages P<0, 1, 2, 3, 4, ...>. In addition, although not specifically shown in the figure, each of the pages P<0, 1, 2, 3, 4, ...> may include multiple memory cells. Among them, according to the number of bits that can be stored or represented in a single memory cell, the memory cells are classified into any of different types of memory blocks such as single-level cell (SLC) memory blocks and multi-level cell (MLC) memory blocks. Here, the SLC memory block includes multiple pages implemented by each memory cell storing one bit of data. The SLC memory block can have higher data I / O operation performance and higher durability. The MLC memory block includes multiple pages implemented by each memory cell storing multiple bits of data (for example, two or more bits). Compared with the SLC memory block, the MLC memory block can have a larger storage capacity for the same space. In terms of storage capacity, the MLC memory block can be highly integrated. In an embodiment, the memory device 104 may be implemented using memory blocks such as double level cells (DLC), trinary level cells (TLC), quad level cells (QLC), or combinations of the above types of level cells. An MLC memory block may include multiple pages implemented by memory cells each capable of storing 2 bits of data. A trinary level cell (TLC) memory block may include multiple pages implemented by memory cells each capable of storing 3 bits of data. A quad level cell (QLC) memory block may include multiple pages implemented by memory cells each capable of storing 4 bits of data. In other embodiments, the memory device 104 may include a memory block consisting of memory cells each capable of storing 5 or more bits of data.

[0092] FIG5 is a schematic diagram illustrating the interaction between a host and a memory system, based on the aforementioned exemplary electronic device having a memory system. FIG5 includes two processes: a process in which the host sends an input / output (I / O) request to the memory system via a sending thread (i.e., a sending kernel thread); and a process in which the host receives data related to the I / O request from the memory system via a receiving thread (i.e., a receiving kernel thread). In the former process, the host uses multiple sending kernel threads to send I / O requests to the memory system via doorbell registers. Each sending kernel thread requires a large amount of lock protection to protect shared data during operation, resulting in a large amount of lock overhead and a long time spent on locking and unlocking processes, making access to the memory system inefficient. In the latter process, the host receives data related to the I / O request from the memory system via interrupt registers and doorbell registers. In this process, the host operating system uses an interrupt mechanism implemented by interrupt context switching. This receiving method requires a large amount of time to process operations such as saving and restoring registers and memory page tables, and updating kernel-related data structures, resulting in high system overhead. Because the host's operating system manages peripherals connected to the host (including memory systems, such as storage devices), the peripherals' speed is much lower than the operating speed of the host's first processor, making it impossible for the host's first processor to constantly monitor the peripheral's status. Therefore, an interrupt mechanism is introduced. The interrupt mechanism can be understood as follows: when the peripheral needs the operating system to process peripheral-related events (read or write), it can proactively notify the operating system, interrupting normal execution between the operating system and the host's application (APP), allowing the operating system to complete the peripheral-related processing, and then resuming normal execution between the operating system and the APP. During the above-mentioned interruption process, interrupt context switching is required. For example, the interruption of normal execution between the operating system and the host's APP to allow the operating system to complete the peripheral-related processing described above is an example of an interrupt context switch. For another example, resuming normal execution between the operating system and the host's APP after completing the peripheral-related processing is also an example of an interrupt context switch. Interrupt context switching requires a significant amount of time to process operations such as saving and restoring registers and memory page tables, and updating kernel-related data structures, resulting in significant system overhead.

[0093] In view of this, in order to solve the above technical problems, an embodiment of the present disclosure provides a host, which binds a first thread and a second thread (a sending kernel thread and a receiving thread) on two CPU cores of a processor included in the host, respectively, so as to use a dedicated sending kernel thread to send I / O requests, and use a dedicated receiving thread to receive feedback values ​​of I / O requests, so as to greatly reduce lock and time overhead.

[0094] As shown in FIG6 , it shows a structural diagram of a host provided by an embodiment of the present disclosure. Specifically, the host 600 includes: a processor 601; the processor 601 includes: a first central processing unit (CPU) core 6011-1 bound to a first thread and a second CPU core 6011-2 bound to a second thread; wherein,

[0095] The first CPU core 6011-1 is configured to: send an input / output (I / O) request to a storage device coupled to a host in response to control of the first thread;

[0096] The second CPU core 6011 - 2 is configured to: receive feedback information related to the I / O request sent by the storage device 800 in response to the control of the second thread.

[0097] It should be noted that the operating system of the host 600 can be a Linux operating system, that is, the processor 601 here can run a Linux operating system. Among them, the Linux operating system is an interactive system developed from UNIX. It is the first layer of software running on the host 600 and is mainly responsible for the allocation and control of all hardware contained in the host. It also provides services for the operation of upper-layer software (such as system software and application software). In actual application, from smart phones to cars, supercomputers and home appliances; from home desktops to enterprise servers, the Linux operating system is widely used. In some embodiments, the storage device can be, but is not limited to, a universal flash storage (UFS) device.

[0098] For understanding of the Linux operating system, please refer to Figures 7 and 8. Figure 7 shows a schematic diagram of the structure of the Linux operating system; Figure 8 shows a schematic diagram of the kernel structure of the Linux operating system.

[0099] As shown in Figure 7, a complete Linux operating system consists of four main components: hardware, the Linux kernel, operating system services, and user apps. User apps primarily refer to word processors, internet browsers, or user-developed apps (such as Taobao and Alipay). Operating system services primarily refer to programs that provide user services and are considered part of the operating system's functionality. In the Linux operating system, these programs include system programs such as shell command parsing and the Linux kernel programming interface. The Linux kernel primarily abstracts and schedules access to hardware resources. Hardware includes, but is not limited to, the CPU, memory, hard disk, and storage devices (also known as peripherals).

[0100] Figure 8 shows the Linux kernel structure. The Linux kernel resides in hardware memory, primarily responsible for I / O interaction, memory management, and controlling CPU access. Figure 8 also includes interrupts and the scheduler. Interrupts are the primary means by which the Linux operating system interacts with peripherals. The scheduler comes into play when an interrupt occurs. Low-level code stops the running process, saves its state in the kernel process structure, and starts the driver. Process scheduling also occurs when the kernel completes certain operations and starts user processes. The scheduler in Figure 8 is the dispatcher. Note that the scheduler here refers to the dispatcher, not the scheduler. There is a difference between the two. Both the scheduler and the dispatcher are concepts related to process (or thread) scheduling. The difference is that the scheduler randomly selects a process from among several processes, while the dispatcher allocates the CPU to the process selected by the scheduler.

[0101] As shown in Figure 8, the Linux kernel is divided into three parts: I / O component, memory component and process component.

[0102] The I / O components are all kernel components responsible for interacting with peripherals and performing network and storage I / O operations. As shown in the Linux kernel's structural diagram (Figure 8), the I / O components include: the top-level virtual file system (VFS), which means that all files, whether from memory or disk (or other storage devices), must first be processed by the virtual file system; the bottom-level character device driver structure, block device driver structure, and network driver structure. The character device driver structure includes terminals that transmit in character units (such as keyboards, printers, etc.) and the character device drivers (programs) that drive these terminals; the block device driver structure includes the file system, I / O scheduler, and block device drivers (programs); and the network driver structure includes the socket network protocol and network driver devices.

[0103] Here, the file system is a system used by Linux to identify files on storage devices (such as disks, NAND flash, etc.) or partitions. It provides a mapping conversion from one layer of files to the physical block layer of storage devices, that is, a system for organizing files on storage devices. The I / O scheduler may refer to a program or structure that performs some scheduling processing on the I / O requests provided by the file system. The main difference between the character device driver and the block device driver is whether random access is allowed. The character device driver cannot be randomly accessed and reads and writes sequentially in byte streams; the block device driver uses fixed-size blocks as units and can be randomly accessed. The network driver device here is not an independent driver device, it is actually a character device, but the processing methods of the two are different. For socket network protocols, it can be, but is not limited to: TCP / IP, UDP, etc.

[0104] The memory component, into which the program is loaded and executed by the CPU. The process of loading the program involves: virtual memory, page replacement, and page cache, etc.

[0105] The process component is responsible for process creation, termination, and scheduling (that is, the process of assigning processes to corresponding CPUs). The Linux kernel regards both processes and threads as runnable entities and uses a unified scheduling policy for scheduling.

[0106] As shown in Figure 8, the Linux kernel's top layer is the system call interface, through which all system calls pass. During a system call, the system call passes the I / O request from the application running in user mode to the Linux kernel running in kernel mode. The Linux kernel then calls the corresponding kernel function to complete the required processing and returns the result to the application.

[0107] The Linux operating system is a multiprogramming system in which independent processes run simultaneously. Each process independently owns its necessary resources and runs independently. The Linux operating system implements multitasking by rotating these processes in short time intervals, where these short time intervals are called time slices. This process rotation is called process scheduling, and the program that performs this process scheduling is called a scheduler. Each process has exclusive access to the processor 601 while running. Because switching between processes is costly, process creation is slow, and process scheduling consumes a lot of resources, threads are used. In some embodiments, a process can include at least one thread. A thread is an execution path within a process, the smallest unit of program execution, and the basic unit of processor core scheduling. In an operating system, unlike processes that independently own their necessary resources, threads do not exclusively own any resources beyond those required for execution (such as the CPU core's program counter, registers, and stack). Instead, threads within the same process share all resources within that process. Threads can be categorized as user-level threads (ULTs) and kernel-level threads (KLTs), depending on whether their schedulers are inside or outside the Linux kernel. ULTs have schedulers outside the Linux kernel, while KLTs have schedulers inside the kernel. A ULT can be a thread created in user space via the thread library; its creation, scheduling, destruction, and communication are all performed in user space. The Linux kernel is unaware of ULTs and does not directly schedule them. The Linux kernel's scheduling targets are still processes. This means that the Linux kernel does not allocate resources to ULTs; ULTs compete for resources only within the same process. Consequently, if a ULT is blocked in the Linux kernel, all other threads in the same process will be blocked, limiting the ULT's concurrency.

[0108] Based on this, KLT is created in the Linux kernel. The Linux kernel can perceive and manipulate KLT through the data structure contained in KLT, so the Linux kernel can use KLT to achieve concurrency between ULTs in the same process.

[0109] Specifically, see Figure 9, which illustrates the mapping relationship between ULTs and KLTs in the Linux operating system. As shown in Figure 9, in the Linux operating system, a one-to-one mapping relationship is often used between ULTs and KLTs. That is, one ULT is mapped to one KLT, and the execution of the ULT must rely on the KLT. Specifically, the operating system scheduler within the Linux kernel dispatches the KLT mapped with the ULT to the corresponding CPU core for execution. As shown in Figure 9, assume that a process includes CPU cores 0 and 1. Three processes, A, B, and C, are created in user space. Process A contains three user threads, ULT1 through ULT3; process B contains two user threads, ULT4 and ULT5; and process C contains one user thread, ULT6. In kernel space, each ULT corresponds to one KLT, meaning that ULT1 through ULT6 correspond to KLT1 through KLT6, respectively. In this case, the processor can simultaneously run two kernel threads mapped to user threads. For example, KLT2 runs on CPU core 0, while KLT3 runs on CPU core 1. Here, user space can refer to the space that users can operate, such as the user APP and operating system service program (layer) shown in Figure 7 above, which all belong to the user space. Kernel space can refer to the space that users cannot operate, which is completed by the Linux kernel, such as the Linux kernel program (layer) shown in Figure 7 above, which belongs to the kernel space.

[0110] By adopting the above mapping method, the Linux kernel can perceive and manipulate KLT through the data structure contained in KLT, and then the Linux kernel can use KLT to achieve concurrency between ULTs in the same process.

[0111] For example, see Figures 10 and 11. Figure 10 shows a schematic diagram of the ULT call relationship when the KLT is not included; Figure 11 shows a schematic diagram of the ULT call relationship when the KLT is included. As shown in Figure 10, ULT1 of process 1 sends a data download request to a website via the network card. The network card is driven and managed by the operating system, so ULT1's data download request (GetData) must be completed by entering the Linux kernel through a system call. While waiting for a network connection, the operating system controls the CPU to switch to process 2 instead of switching to ULT2 of process 1. This is because the operating system is unaware of the existence of ULT2 (the thread control block (TCB) information corresponding to the ULT is in user space) and can only call the schedule function to complete the process switch. Therefore, if a ULT is blocked in the Linux kernel, all ULTs of that process will be blocked, limiting the concurrency of the ULTs.

[0112] As shown in Figure 11, the KLT is created in the Linux kernel. The KLT's TCB and other information are all created in the Linux kernel. Through these data structures, the Linux kernel can perceive and manipulate the KLT to achieve concurrency between ULTs within the same process. In other words, without the KLT, the Linux kernel can only switch between processes, as shown in Figure 10. With the KLT, the Linux kernel can switch between ULTs within the same process, as shown in Figure 11. Creating the KLT in the Linux kernel enables concurrency between ULTs.

[0113] In some embodiments, KLT is more suitable for multi-CPU core processors than processes, as shown in Figures 12 to 14.

[0114] 1. If there are two ULTs. As shown in Figure 12, a process 1 contains two threads ULT1 and ULT2. Because the operating system cannot perceive the ULT, it is impossible to schedule the two ULTs. They can only work in one CPU core (such as CPU core 1), and the other CPU core (such as CPU core 2) is always idle. The Yield here is the Yield function, which is used to save the stack of the thread executed by the current CPU core, and take out the stack pointer of the thread to be executed, and assign it to the register to start execution. The Yield function is a very important concept in concurrent programming. There is no restriction on the memory management unit and bus shown in Figure 12 in the present disclosure, and any bus and memory management unit that can support the technical solution of the present disclosure can be used.

[0115] 2. Consider two processes. As shown in Figure 13, Process 1 and Process 2, where Process 1 contains ULT1 and Process 2 contains ULT3. In this case, the Linux operating system can schedule the two processes to run on two separate CPU cores. This appears to allow for parallel execution, but the shared memory resources of multi-core processors make it impossible to query the mapping tables of both processes simultaneously. Therefore, the two processes are actually concurrent, not parallel. This fails to fully utilize the advantages of multi-core processors.

[0116] 3. Consider two KLTs. As shown in Figure 14, process 1 contains two threads, ULT1 and ULT2, each corresponding to a KLT. Because KLTs are built into the Linux kernel, the Linux operating system can schedule them. Threads within the same process can share memory resources, eliminating process bottlenecks. This accelerates hardware processing and enables parallel execution.

[0117] For multi-CPU core processors, when a KLT in the Linux kernel is scheduled, the CPU core to which it is assigned is determined by the scheduling algorithm in the Linux kernel's scheduler (such as the dispatcher). The CPU core to which a KLT is assigned is not fixed. Furthermore, since a ULT is an execution unit within a process, it can run in parallel with other ULTs in the same process on different CPU cores through multiple KLTs. Furthermore, since ULTs share the same process's resources, such as memory, address space, and open file resources, it is necessary to implement mutual exclusion, locking, and serialization mechanisms between the various KLTs to ensure the consistency and synchronization of shared data (such as global data). In other words, when multiple KLTs are assigned to multiple CPU cores for execution, to prevent KLTs on multiple CPU cores from accessing global data simultaneously, when a KLT on a particular CPU core accesses global data, additional lock protection is required to ensure that the KLT on that CPU core can access the global data, while other CPU cores cannot access all of the data. This creates a technical problem, as shown in Figure 5: when using multiple KLTs, a large amount of lock protection is required, resulting in a significant amount of lock overhead.

[0118] To solve the above technical problems, the present disclosure provides a host as shown in Figure 6, which binds a first thread to a first CPU core to use a dedicated sending kernel thread to send I / O requests; and binds a second thread to a second CPU core to use a dedicated receiving thread to receive feedback values ​​of I / O requests, thereby reducing the locking overhead required when using shared global data. The first CPU core and the second CPU core can both be included in a processor core 6011, that is, the processor 601 shown in Figure 6 can be the first processor 201 described above, which can be a processor with multiple CPU cores. Based on this, in some embodiments, the first CPU core and the second CPU core can refer to two of the aforementioned multiple CPU cores, and the first CPU core can be any CPU core in the multiple CPU cores; the second CPU core can be any CPU core in the multiple CPU cores except the first CPU core. The first thread described here can be a sending kernel thread in the Linux kernel; the second thread described can be a receiving kernel thread in the Linux kernel.

[0119] Binding can be understood as follows: binding the first thread to the first CPU core means that the first CPU core is dedicated to processing the first thread, and the first thread is only assigned to the first CPU core to run. In other words, the first CPU core is only controlled by the first thread. Similarly, binding the second thread to the second CPU core means that the second CPU core is dedicated to processing the second thread, and the second thread is only assigned to the second CPU core to run. By binding kernel threads to run on dedicated CPU cores in this way, the number of first threads (such as sending kernel threads) and second threads used can be reduced, thereby reducing the number of locks used to protect global data, thereby reducing lock overhead; and reducing the time overhead required for lock protection.

[0120] In some embodiments, the I / O request may be generated by an application running on a processor, and the I / O request is converted by a device driver running on the processor into one or more request commands in a format supported by the storage device.

[0121] That is, the I / O request may be generated by the APP and converted by the device driver into one or more request commands in a format supported by the storage device and sent to the storage device. The device driver may refer to the block device driver shown in FIG8 .

[0122] This section describes how I / O requests are transmitted from an app to a device driver, using a Linux-based storage system as an example.

[0123] As shown in Figure 15, a Linux-based storage system includes the VFS layer, file system layer, Page Cache layer, general block layer, I / O scheduling layer, block device driver layer, and block device layer. The interactions between the various layers of the Linux-based storage system are shown in Figures 16 to 20.

[0124] The specific interaction process can be as follows: When the host initiates a random read or write of a data page, or a sequential read or write of a log file, the host processor will actually hand over the I / O request generated by the APP to the VFS layer of the Linux operating system. The role of the VFS layer is to perform I / O operations on files in the selected directory according to the host processor, and hand over the I / O request to the specific file system. For example, in Linux, some directories such as / AA1 / AA2 are actually managed by the NFS file system, and some directories such as / AA3 / AA4 are actually managed by the Ext3 file system. At this time, the VFS layer needs to determine the read and write I / O requests initiated for files under the selected directory (for example, the selected directory is / AA1 / AA2) and forward the request to the corresponding file system (such as NFS), as shown in Figure 16.

[0125] The file system then searches the memory-based cache (Page Cache layer) to see if the required data is there. If so, it performs read and write operations based on the memory cache. If not, it proceeds to the next layer. At this point, the I / O request is handed over to the general block layer, which converts the file I / O request into a block I / O request, as shown in Figure 17.

[0126] After the I / O request is converted into a block I / O request, it is handed off to the I / O scheduling layer, as shown in Figure 18. This layer sorts multiple block I / O requests and determines the order in which each block I / O request is sent. The scheduling algorithm used can be the Completely Fair Scheduler (CFQ) algorithm or the deadline I / O scheduling algorithm.

[0127] Finally, after the I / O request is scheduled, it will be decided which Block I / O request will be executed first and which Block I / O request will be executed later. At this time, the executable Block I / O request will be handed over to the Block device driver layer (running the device driver), and then finally the Block device driver layer will convert the I / O request into one or more request commands and send them to the actual storage hardware (storage device), that is, the Block device layer, as shown in Figure 19.

[0128] After the storage device completes the I / O read / write operation, either a write operation or an operation, it returns the response in reverse order through the above layers. Finally, the host side can obtain the result of this I / O read / write operation, as shown in Figure 20.

[0129] In some embodiments, the I / O request may refer to, but is not limited to, a read request, a data storage (or write) request, or a data discard request.

[0130] In some embodiments, as shown in FIG21 , the processor 601 further includes: a device interface 6012; the device interface includes: a host controller interface (HCI) 6012A; the host controller interface includes an interrupt register 6012A-1;

[0131] The second CPU core 6011 - 2 is further configured to: in response to the control of the second thread, poll the interrupt register to receive feedback information.

[0132] In some embodiments, the second CPU core 6011-2 is specifically configured to: in response to the control of the second thread, periodically access the interrupt register at preset time intervals to determine whether feedback information is received in the interrupt register; if feedback information is received, obtain the feedback information from the interrupt register.

[0133] It should be noted that the above description only describes some operations of the second CPU core when the second thread is running. When the second thread is a receiving kernel thread, the second CPU core, in response to the control of the second thread, polls the interrupt register included in the HCI to receive feedback information related to the aforementioned I / O request. The feedback information may refer to return data such as that shown in Figure 20.

[0134] The process described herein of the second CPU core polling the interrupt register in response to the control of the second thread may include the second CPU core periodically accessing the interrupt register at a preset time interval, wherein the preset time interval may be set according to actual conditions.

[0135] The present disclosure adopts a polling strategy when receiving feedback information, so that the entire process of receiving feedback information can be completed in one thread. Compared with the interrupt processing mechanism, a large amount of overhead caused by interrupt context switching in the interrupt processing mechanism is eliminated.

[0136] In some embodiments, as shown in FIG22 , the host 60 further includes a memory 602 ; the memory 602 is configured to store a request command queue; the request command queue includes: one or more request commands; the one or more request commands correspond to one or more I / O requests;

[0137] The first CPU core 6011 - 1 is configured to: in response to the control of the first thread, obtain one or more request commands from the request command queue, and send the one or more request commands to the storage device.

[0138] It should be noted that, as previously described, after an I / O request is converted by the device driver, it is converted into one or more request commands. These request commands are stored in memory in the form of a queue, forming a request command queue. This request command queue can be a sequential queue or a linked list queue. The sequential queue uses a first-in-first-out constraint, while the linked list queue can use a first-in-first-out constraint or other constraints, such as first-in-last-out.

[0139] Specifically, the present disclosure only uses a first-in-first-out constrained queue to illustrate the role and use of the request command queue. That is, the first CPU core 6011-1 obtains the request command from the memory in the order in which the request command is stored, and sends the request command. Here, the memory 602 can be the same as the aforementioned memory 304, and can include a program memory for storing write data and read data, a data memory, a write buffer / cache, a read buffer / cache, a data buffer / cache, and a mapping buffer / cache. The memory 602 can be implemented using a volatile memory. The memory 602 can be implemented using a static random access memory (SRAM), a dynamic random access memory (DRAM), or both.

[0140] In some embodiments, as shown in Figures 21 and 22, the host controller interface 6012A further includes: a doorbell register 6012A-2;

[0141] The second CPU core 6011 - 2 is further configured to access the doorbell register to determine the I / O request corresponding to the feedback information.

[0142] In some embodiments, the first CPU core is further configured to: access the doorbell register to allocate a required transmission channel for the I / O request in the ready state.

[0143] It should be noted that the doorbell register is also referred to as the Doorbell register. The Doorbell register provides a channel for multiple CPU cores to issue request commands (including a transmission channel for request commands from the host side to the storage device side). Each CPU core can send a request command to the storage device through the Doorbell register or receive feedback information of the request command through the Doorbell register and determine the I / O request corresponding to the received feedback information. In other words, both the first CPU core and the second CPU core need to obtain the data transmission channel or the source of the data by accessing the Doorbell register.

[0144] In the present disclosure, for access to the Doorbell register, in some embodiments, the doorbell register is accessed in a locked access mode, wherein the locked access mode includes that the doorbell register is only accessed by the first CPU core or the second CPU core at the same time.

[0145] That is, the Doorbell register can only be accessed by the first CPU core or the second CPU core at the same time. Taking the first CPU core as an example, when the first CPU core sends a request command through the Doorbell register, the Doorbell register will be locked, and the second CPU core will not be able to access the Doorbell register.

[0146] Specifically, the Doorbell register may contain 32 bits, each representing a downlink channel through which the host sends an I / O request to the storage device. In some embodiments, the bit corresponding to the used downlink channel in the Doorbell register is set to 1, while the remaining bits remain at 0. Based on this, the specific process described in this disclosure for a first CPU core accessing the Doorbell register to allocate the required transmission channel for an I / O request in a ready state may be as follows: the first CPU core first traverses the 32 downlink channels (also known as transmission channels) contained in the Doorbell register and identifies a downlink channel that is not occupied by other CPU cores. The flag bit associated with an unoccupied downlink channel may be 0, while the flag bit associated with an occupied downlink channel may be 1. The first CPU core sets the flag bit of the selected unoccupied downlink channel from 0 to 1, thereby indicating that the downlink channel is occupied. The first CPU core sends a request command to the storage device via this downlink channel. After sending the request command, the first CPU core unlocks the Doorbell register, allowing other CPU cores (such as the second CPU core) to access the Doorbell register.

[0147] The specific process for the second CPU core 6011-2 described herein to access the doorbell register to determine the I / O request corresponding to the feedback information can be as follows: The current value of the doorbell register is read and compared with a list of previously issued, but still uncompleted, commands from the host. Each bit in the doorbell register that is 0 indicates that the request command has been completed, while each bit in the doorbell register that is 1 indicates that the request command has not been completed. Because the doorbell register is locked for access, only one bit in the doorbell register is 1 each time a request command is sent, thus determining the I / O request corresponding to the feedback information.

[0148] In some embodiments, as shown in FIG23 , the device interface further includes: a joint protocol circuit and an M-physical interface circuit 6012B, wherein;

[0149] The joint protocol circuit and the M-physical interface circuit are connected to the host controller interface and are configured to send a request command to the storage device or receive feedback information sent by the storage device, wherein the request command is generated based on the I / O request.

[0150] It should be noted that the Unified Protocol (UniPro) circuit and M-PHY (M-physical layer) circuit 6012B may be the host-side UFS Interconnect (UIC) layer, which is the interface for the host to directly connect to the storage device. The specific implementation of the UniPro circuit and the M-PHY circuit can refer to the UniPro protocol and the M-PHY protocol, which will not be described in detail.

[0151] In order to understand the present disclosure, refer to Figure 24, which shows a flow chart of the host sending I / O requests to the storage device and receiving feedback information provided by an embodiment of the present disclosure. In Figure 24, the sending thread is bound to CPU core X and the receiving thread is bound to CPU core Y. When the host sends a request command to the storage device, the sending thread on CPU core X is used to obtain the request command from the request command queue stored in the memory in a first-in-first-out manner, and the obtained request command is sent to the storage device. When the host receives the feedback information sent by the storage device, the receiving thread on CPU core Y is used to access the interrupt register in a polling manner, and when the interrupt register receives the feedback information, the feedback information is processed. That is, two dedicated CPU cores are used to process the I / O requests between the host and the storage device, which reduces a lot of overhead.

[0152] Based on the same inventive concept, an embodiment of the present disclosure further provides a host information processing method, as shown in FIG25 , which may include:

[0153] S2501: Bind a first thread to a first central processing unit (CPU) core included in a host;

[0154] S2502: Bind the second thread to the second CPU core included in the host; when the first thread is running, control the first CPU core to send an input / output (I / O) request to a storage device coupled to the host; when the second thread is running, control the second CPU core to receive feedback information related to the I / O request sent by the storage device.

[0155] In some embodiments, when the second thread is running, controlling the second CPU core to receive feedback information related to the I / O request from the storage device further includes:

[0156] When the second thread is running, the second CPU core is controlled to poll the interrupt register included in the host to receive feedback information.

[0157] In some embodiments, controlling the second CPU core to poll the interrupt register included in the host to receive feedback information includes: regularly accessing the interrupt register at a preset time interval to determine whether feedback information is received in the interrupt register; if feedback information is received, obtaining the feedback information from the interrupt register.

[0158] In some embodiments, when the first thread is running, controlling the first CPU core to send an input / output (I / O) request to a storage device coupled to the host includes:

[0159] When the first thread is running, controlling the first CPU core to obtain one or more request commands from a request command queue stored in a memory of the host, and sending the one or more request commands to the storage device;

[0160] One or more request commands correspond to one or more I / O requests.

[0161] In some embodiments, the method further comprises:

[0162] When the first thread is running, the first CPU core is controlled to access the doorbell register included in the host, and the required transmission channel is allocated for the I / O request in the ready state;

[0163] When the second thread is running, the second CPU core is controlled to access the doorbell register to determine the I / O request corresponding to the feedback information.

[0164] In some embodiments, the doorbell register is accessed in a locked access mode, wherein the locked access mode includes that the doorbell register is only accessed by the first CPU core or the second CPU core at the same time.

[0165] It should be noted that the information processing method of the host provided in the embodiment of the present disclosure belongs to the same inventive concept as the host provided above. The specific implementation of each step described here has been described in detail above, and can be understood by referring to the above description, so it will not be repeated here.

[0166] The present disclosure also provides an electronic system 2600, as shown in FIG26 , which may include:

[0167] Host 2601; the host includes a processor; the processor is configured to: bind a first thread to a first central processing unit (CPU) core included in the processor; and bind a second thread to a second CPU core included in the processor; run the first thread, and control the first CPU core to send an input / output (I / O) request to a storage device;

[0168] and a storage device 2602 coupled to the host; the storage device is configured to: receive and process I / O requests; generate feedback information related to the I / O requests; and send feedback information to the host;

[0169] The processor is further configured to: run a second thread and control the second CPU core to receive feedback information sent by the storage device.

[0170] In some embodiments, the processor further comprises: a device interface; the device interface comprises a host controller interface; the host controller interface comprises an interrupt register;

[0171] The second CPU core is further configured to: in response to the control of the second thread, periodically send a first access command to the interrupt register according to a preset time interval;

[0172] The interrupt register is configured to: in response to the first access command, send feedback information to the second CPU core when receiving feedback information sent by the storage device.

[0173] In some embodiments, the host further comprises a memory; the memory is configured to store a request command queue; the request command queue comprises one or more request commands; the one or more request commands correspond to one or more I / O requests;

[0174] The first CPU core is further configured to: send a second access command to the memory in response to control of the first thread;

[0175] The memory is configured to: in response to the second access command, obtain one or more request commands from the request command queue and send the one or more request commands to the first CPU core;

[0176] The first CPU core is further configured to: send one or more request commands to the storage device.

[0177] It should be noted that the "first" and "second" in the first access command and the second access command appearing here are only for the convenience of describing the access commands in different processes and are not used to limit the quantity. That is: the first access command is the access command sent by the second CPU core when accessing the interrupt register; the second access command is the access command sent by the first CPU core when accessing the memory. The electronic system provided by the embodiment of the present disclosure includes the host provided above. For the description of the host, please refer to the aforementioned description of the host, which will not be repeated here. The storage device includes a storage system such as that shown in Figures 1 to 5 above, which will not be repeated here.

[0178] The present disclosure also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the above methods. The aforementioned storage medium includes various media capable of storing program code, such as a mobile storage device, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0179] It should be noted that in the several embodiments provided in the present disclosure, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0180] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0181] In addition, all functional units in the embodiments of the present disclosure may be integrated into one processing unit, or each unit may be separately used as a unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0182] Those skilled in the art will appreciate that all or part of the steps of the above-mentioned method embodiments may be implemented by hardware associated with program instructions, and the aforementioned program may be stored in a computer-readable storage medium. When the program is executed, the program executes the steps of the above-mentioned method embodiments. The aforementioned storage medium includes various media that can store program codes, such as mobile storage devices, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical disks.

[0183] Alternatively, if the above-mentioned integrated unit of the present disclosure is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present disclosure is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in each embodiment of the present disclosure. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROM, RAM, magnetic disks or optical disks.

[0184] The above description is merely a specific embodiment of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this disclosure should be included in the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure should be based on the scope of protection of the claims.

Claims

1. A host, comprising: processor; The processor includes: a first central processing unit (CPU) core bound to a first thread and a second CPU core bound to a second thread; wherein, The first CPU core is configured to: send an input / output (I / O) request to a storage device coupled to the host in response to control of the first thread; The second CPU core is configured to: in response to the control of the second thread, receive feedback information related to the I / O request sent by the storage device.

2. The host according to claim 1, wherein: The processor further comprises: a device interface; the device interface comprises: a host controller interface; the host controller interface comprises an interrupt register; The second CPU core is further configured to: in response to the control of the second thread, poll the interrupt register to receive the feedback information.

3. The host according to claim 2, wherein: The second CPU core is specifically configured to: in response to the control of the second thread, periodically access the interrupt register at a preset time interval to determine whether the feedback information is received in the interrupt register; if the feedback information is received, obtain the feedback information from the interrupt register.

4. The host according to claim 1, wherein: The host also includes a memory; the memory is configured to store a request command queue; The request command queue includes: one or more request commands; the one or more request commands correspond to one or more I / O requests; The first CPU core is configured to: in response to the control of the first thread, obtain the one or more request commands from the request command queue, and send the one or more request commands to the storage device.

5. The host according to claim 2, wherein: The host controller interface also includes: a doorbell register; The second CPU core is further configured to: access the doorbell register to determine the anti- I / O request corresponding to the feedback information.

6. The host according to claim 5, wherein: The first CPU core is further configured to: access the doorbell register to allocate a required transmission channel for the I / O request in the ready state.

7. The host according to claim 6, wherein: The access mode of the doorbell register is a locked access mode, wherein the locked access mode includes that the doorbell register is only accessed by the first CPU core or the second CPU core at the same time.

8. The host according to claim 1, wherein: The I / O request is generated by an application program running on the processor, and the I / O request is converted into one or more request commands in a format supported by the storage device by a device driver running on the processor.

9. The host according to claim 2, wherein: The device interface further comprises: a joint protocol circuit and an M-physical interface circuit, wherein; The joint protocol circuit and the M-physical interface circuit are connected to the host controller interface and are configured to: send a request command to the storage device or receive the feedback information sent by the storage device, wherein the request command is generated based on the I / O request.

10. The host according to claim 1, wherein: The storage device is a Universal Flash Storage (UFS) device.

11. The host according to claim 1, wherein: The operating system running in the host is the Linux operating system.

12. The host according to claim 1, wherein: The processor includes multiple CPU cores, wherein the first CPU core is any one of the multiple CPU cores; and the second CPU core is any one of the multiple CPU cores except the first CPU core.

13. A host information processing method, comprising: Binding a first thread to a first central processing unit (CPU) core included in the host; Binding the second thread to a second CPU core included in the host; When the first thread is running, the first CPU core is controlled to couple with the host The connected storage device sends an input / output (I / O) request; when the second thread is running, the second CPU core is controlled to receive feedback information related to the I / O request sent by the storage device.

14. The method according to claim 13, wherein: When the second thread is running, controlling the second CPU core to receive feedback information related to the I / O request sent by the storage device also includes: When the second thread is running, the second CPU core is controlled to poll the interrupt register included in the host to receive the feedback information.

15. The method according to claim 14, wherein: The controlling the second CPU core to poll the interrupt register included in the host to receive the feedback information includes: regularly accessing the interrupt register at a preset time interval to determine whether the feedback information is received in the interrupt register; if the feedback information is received, obtaining the feedback information from the interrupt register.

16. The method according to claim 13, wherein: When the first thread is running, controlling the first CPU core to send an input / output (I / O) request to a storage device coupled to the host includes: When the first thread is running, control the first CPU core to obtain one or more request commands from a request command queue stored in a memory of the host, and send the one or more request commands to the storage device; The one or more request commands correspond to one or more I / O requests.

17. The method according to claim 14, wherein: The method further comprises: When the first thread is running, controlling the first CPU core to access the doorbell register included in the host to allocate a required transmission channel for the I / O request in a ready state; When the second thread is running, the second CPU core is controlled to access the doorbell register to determine the I / O request corresponding to the feedback information.

18. The method according to claim 17, wherein: The access mode of the doorbell register is a locked access mode, wherein the locked access mode includes that the doorbell register is only accessed by the first CPU core or the second CPU core at the same time.

19. An electronic system comprising: A host; the host includes a processor; the processor is configured to: bind a first thread to a first central processing unit (CPU) core included in the processor; and binding the second thread to a second CPU core included in the processor; running the first thread and controlling the first CPU core to send an input / output (I / O) request to the storage device; and a storage device coupled to the host; the storage device being configured to: receive and process the I / O request; generate feedback information related to the I / O request; and send the feedback information to the host; The processor is further configured to: run the second thread and control the second CPU core to receive the feedback information sent by the storage device.

20. The electronic system according to claim 19, wherein: The processor further comprises: a device interface; the device interface comprises a host controller interface; the host controller interface comprises an interrupt register; The second CPU core is further configured to: in response to the control of the second thread, periodically send a first access command to the interrupt register at a preset time interval; The interrupt register is configured to: in response to the first access command, send the feedback information to the second CPU core when receiving the feedback information sent by the storage device.

21. The electronic system according to claim 19, wherein: The host further comprises a memory; the memory is configured to store a request command queue; the request command queue comprises one or more request commands; the one or more request commands correspond to one or more I / O requests; The first CPU core is further configured to: send a second access command to the memory in response to control of the first thread; The memory is configured to: in response to the second access command, obtain the one or more request commands from the request command queue, and send the one or more request commands to the first CPU core; The first CPU core is further configured to: send the one or more request commands to the storage device.

22. A computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the method according to any one of claims 13 to 18 when executed by a processor.

Images