Data processing method and apparatus

Abstract

A data processing method. The method comprises: when an instance of a target core writes a system log, on the basis that a space that has been allocated to the instance of the target core and is used for storing system logs is insufficient, allocating a first space and a second space to the instance of the target core, wherein the system log is used for recording a system state, the first space stores the system log, the second space stores metadata for managing the first space, and the instance of the target core exclusively occupies the first space and the second space; and the instance of the target core writing the system log into the first space. In the present application, when a core actually writes data, and when a space that has been allocated to an instance and is used for storing system logs is insufficient, a space that can be exclusively occupied by the core is newly allocated to the core, so as to write a system log, thereby ensuring the characteristic of high space utilization.

Description

Data processing method and apparatus thereof

[0001] The present application claims priority to the Chinese Patent Application No. 202410808218.3, filed on June 20, 2024, and entitled "A Data Processing Method and Apparatus Thereof", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to the field of artificial intelligence, and in particular, to a data processing method and apparatus thereof. BACKGROUND

[0003] Tracing (or can be called Logging) is an important tool for system maintenance. The state of the system (i.e., system log) is recorded in the memory (or further persisted to the disk) through this mechanism, and is read and traced when locating performance or functional problems. With the increasing complexity of software and hardware, a low-performance and space-overhead Tracing tool is increasingly critical for quickly locating performance and functional problems.

[0004] In the prior art, a fixed space is pre-allocated for each core to store system logs and manage metadata of the system logs. When the allocated space is full, the new data will overwrite the old data (i.e., wraparound), which will cause the following problems:

[0005] For some cores, they may be in an idle state for a period of time, which will cause some of the pre-allocated space not to have data written, resulting in space waste. For some cores, they may be in a busy state for a period of time, which will cause the historical old data to be continuously overwritten by new data, resulting in the inability to save very old data and making the real-time performance of the data low. SUMMARY

[0006] In a first aspect, the present application provides a data processing method, comprising: when an instance of a target core writes a system log, allocating a first space and a second space for the instance of the target core based on that the instance of the target core has insufficient space allocated for storing the system log, wherein the system log is used to record the state of the system, the first space stores the system log, the second space stores metadata for managing the first space, and the instance of the target core exclusively uses the first space and the second space; and the instance of the target core writes the system log into the first space.

[0007] In the embodiments of the present application, when the core actually writes data, if the space allocated by the instance for storing system logs is insufficient, the core is newly allocated space for exclusive use of the core to write system logs. That is, only when the core is busy, more space is allocated to the core, which improves the utilization of space. The reason is that in the worst case, assuming that there are M spaces in total and N cores, N-1 cores exclusively use a data block and no new data is generated. At this time, the space utilization rate is 1-(N-1) / M. In contrast, the space utilization rate of the prior art is 1 / N, thereby ensuring the high utilization of space.

[0008] The system log is information recording hardware, software and system problems in the system, and can also monitor events occurring in the system. Users can check the causes of errors or find traces left by attackers when attacked through the system log. The system log includes a system log, an application program log and a security log.

[0009] In addition, when the rate of generating system logs by different cores is different, the embodiments of the present application can ensure that the proportion of new data in the cache is significantly higher than that of the existing Tracing mechanism. In the extreme case, when N-1 CPUs exclusively use the block and generate extremely slow / are blocked, the proportion of the latest data in the total cache is also 1-(N-1) / M, and the proportion of new data of other per-CPU solutions is 1 / N. Therefore, the high real-time characteristic of data is ensured.

[0010] In a possible implementation, the first space and the second space belong to a plurality of spaces globally divided and arranged; the method further includes: reading a first variable; the first variable is used to indicate a space for storing system logs newly allocated for a core in the plurality of spaces; and determining the first space according to the first variable, wherein the first space is a space arranged after the space for storing system logs newly allocated for the core in the plurality of spaces.

[0011] In a possible implementation, the first variable includes a first global variable and a second global variable, the first global variable is used to indicate a number of spaces managed by each metadata, and the second global variable is used to indicate a number of allocated spaces for storing system logs.

[0012] In a possible implementation, the metadata for managing the first space includes a second variable; the second variable is used to indicate a round of writing data, a starting position of writing data and a position of completed writing.

[0013] In a possible implementation, the second space specifically stores metadata for managing the first space and a third space; the method further includes: based on a current existence of instances of other cores performing data writing on the third space, setting an instance of the target core to exclusively use the first space, and instructing the instances of the other cores to exit after completing data writing on the third space; and the instance of the target core writes system logs into the first space, including: after the instances of the other cores exit the third space, the instance of the target core writes system logs into the first space.

[0014] In a possible implementation, the method further includes: updating the first variable when the number of spaces for storing system logs increases or decreases.

[0015] In a possible implementation, after the first variable is updated, the method further includes: expelling each instance of a core performing writing or reading of system logs, so that each core is aware of the updated first variable.

[0016] In a possible implementation, the method further includes: when the number of spaces for storing system logs decreases, determining whether there is an instance performing writing of system logs by accessing information indicating an input writing position in a second variable in each metadata; or, when the number of spaces for storing system logs decreases, determining whether there is an instance performing reading of system logs by accessing a third variable, where the third variable is a global variable that is incremented by 1 each time reading of system logs is started and completed.

[0017] In a possible implementation, the instance of the target core writes system logs into the first space, including: when a first instance of the target core writes system logs in a first address space of the first space and does not complete data writing, a second instance of the target core writes system logs in a second address space of the first space, the second address space being an address space after the first address space; or, a new space other than the first space is allocated for the second instance of the target core to skip the first address space.

[0018] In a possible implementation, the allocating the first space for the instance of the target core includes: based on existence of other instances performing data writing on a fourth space and not completing data writing, allocating the first space for the instance of the target core, where the fourth space is a space for storing system logs after and adjacent to the already allocated space for storing system logs, and the first space is a space for storing system logs after the fourth space.

[0019] In a second aspect, the present application provides a data processing apparatus, the apparatus comprising:

[0020] a space allocation module configured to allocate a first space and a second space for an instance of a target core based on that the instance of the target core has insufficient space allocated for storing system logs when the instance of the target core writes the system logs, wherein the system logs are used to record system states, the first space is used to store the system logs, the second space is used to store metadata for managing the first space, and the instance of the target core exclusively uses the first space and the second space;

[0021] a read-write module configured to write the system logs into the first space.

[0022] In a possible implementation, the read-write module is further configured to:

[0023] read a first variable, wherein the first variable is used to indicate a latest space for storing system logs allocated for a core among the plurality of spaces;

[0024] the space allocation module is further configured to determine the first space according to the first variable, wherein the first space is a space arranged after the latest space for storing system logs allocated for a core among the plurality of spaces.

[0025] In a possible implementation, the first variable comprises a first global variable and a second global variable, wherein the first global variable is used to indicate a number of spaces managed by each metadata, and the second global variable is used to indicate a number of spaces for storing system logs allocated.

[0026] In a possible implementation, the metadata for managing the first space comprises a second variable, wherein the second variable is used to indicate a round of writing data, a start position of writing data, and a position of completed writing.

[0027] It should be understood that the second variable is not limited to one variable, and more variables can be included, for example, one variable is used to indicate the start position, and one variable is used to indicate the position of completed writing.

[0028] In a possible implementation, the second space specifically stores metadata for managing the first space and a third space, and the space allocation module is further configured to, based on the fact that there is currently data writing to the third space by an instance of another core, set the instance of the target core to exclusively use the first space, and instruct the instance of the other core to exit after completing the data writing to the third space.

[0029] the read-write module is specifically configured to:

[0030] After the instances of the other cores exit the third space, the instance of the target core writes system logs into the first space.

[0031] In a possible implementation, the space allocation module is further configured to:

[0032] The first variable is updated when the number of spaces for storing system logs is expanded or reduced.

[0033] In a possible implementation, after the first variable is updated, the space allocation module is further configured to:

[0034] Each instance of a core that writes or reads system logs is evicted so that each core is aware of the updated first variable.

[0035] In a possible implementation, the space allocation module is further configured to:

[0036] When the number of spaces for storing system logs is reduced, it is determined whether there is an instance that writes system logs by accessing information for indicating an input write position in a second variable in each metadata; or,

[0037] When the number of spaces for storing system logs is reduced, it is determined whether there is an instance that reads system logs by accessing a third variable, wherein the third variable is a global variable that is accumulated by 1 each time when reading system logs starts and when reading system logs is completed.

[0038] In a possible implementation, the instance of the target core writes system logs into the first space, including: when a first instance of the target core writes system logs in a first address space of the first space and data writing is not completed, a second instance of the target core writes system logs in a second address space of the first space by skipping the first address space, the second address space being an address space after the first address space; or, a new space other than the first space is allocated for the second instance of the target core to skip the first address space.

[0039] In a possible implementation, the space allocation module is specifically configured to:

[0040] The instance of the target core is allocated the first space based on the existence of other instances that write data in a fourth space and data writing is not completed, wherein the fourth space is a space for storing system logs after and adjacent to the already allocated space for storing system logs, and the first space is a space for storing system logs after the fourth space.

[0041] In a third aspect, an embodiment of the present application provides a data processing apparatus, which can include a memory, a processor and a bus system, wherein the memory is configured to store a program, and the processor is configured to execute the program stored in the memory to perform the method of the first aspect and any possible implementation thereof.

[0042] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, which stores a computer program, and when the computer program is run on a computer, the computer is enabled to perform the method of the first aspect and any possible implementation thereof.

[0043] In a fifth aspect, an embodiment of the present application provides a computer program, which, when run on a computer, enables the computer to perform the method of the first aspect and any possible implementation thereof.

[0044] In a sixth aspect, the present application provides a chip system, which includes a processor configured to support performing the functions involved in the above aspects, for example, sending or processing the data involved in the above method; or, information. In a possible design, the chip system further includes a memory, and the memory is configured to store the program instructions and data necessary for the execution device or the training device. The chip system can be composed of a chip, or can include a chip and other discrete devices. BRIEF DESCRIPTION OF DRAWINGS

[0045] FIG. 1 is a flow diagram of a data processing method according to an embodiment of the present application;

[0046] FIG. 2 is a schematic diagram of a space allocation process;

[0047] FIG. 3 is a flow diagram of a data processing method according to an embodiment of the present application;

[0048] FIG. 4 is a flow diagram of a data processing method according to an embodiment of the present application;

[0049] FIG. 5 is a flow diagram of a data processing method according to an embodiment of the present application;

[0050] FIG. 6 is a processing diagram of a data processing method according to an embodiment of the present application;

[0051] FIG. 7 is a processing diagram of a data processing method according to an embodiment of the present application;

[0052] FIG. 8 is a processing diagram of a data processing method according to an embodiment of the present application;

[0053] FIG. 9A is a schematic diagram of an application architecture according to an embodiment of the present application;

[0054] FIG. 9B is a schematic diagram of an effect according to an embodiment of the present application;

[0055] FIG. 10 is a structural schematic diagram of a data processing apparatus according to an embodiment of the present application;

[0056] FIG. 11 is a structural schematic diagram of an execution device according to an embodiment of the present application;

[0057] FIG. 12 is a structural schematic diagram of a training device according to an embodiment of the present application. DETAILED DESCRIPTION

[0058] The embodiments of the present application will be described below in conjunction with the accompanying drawings. The terms used in the embodiments section of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application.

[0059] The embodiments of the present application will be described below in conjunction with the accompanying drawings. The embodiments of the present application are applicable to similar technical problems as the technology provided by the embodiments of the present application.

[0060] The terms "first", "second", and the like in the specification of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or a chronological sequence. It should be understood that the terms used in this way can be interchanged, and this is only a distinguishing way used in the description of the embodiments of the present application to describe the objects with the same attributes. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, so that the processes, methods, systems, products or devices containing a series of units do not have to be limited to those units, but can include other units not clearly listed or inherent to these processes, methods, products or devices.

[0061] The terms "substantially", "about", and the like used herein are used as approximate terms, not as degree terms, and are intended to take into account the inherent deviations of measured or calculated values known by those skilled in the art. In addition, the use of "may" in the description of the embodiments of the present application means "one or more embodiments". The terms "use", "using", and "used" used herein can be considered as synonymous with the terms "utilize", "utilizing", and "utilized", respectively. In addition, the term "exemplary" is intended to refer to an example or an illustration.

[0062] For ease of understanding, the related terms involved in the embodiments of the present application will be introduced first.

[0063] 1. Tracing, or logging, refers to the process of outputting internal states, decisions, or critical information of a target system to a given buffer via a provided interface during operation. This information can then be read back afterward to analyze the system's behavior.

[0064] 2. Per-CPU / Per-Thread Buffer. Tracing requires generating data into a buffer. This buffer is typically created per core (per-CPU) or per thread (per-thread) to avoid the significant performance overhead of contention for a single buffer. Here, Per-CPU is equivalent to Per-Core, where CPU refers to a single core in the processor.

[0065] 3. Ring-buffer. A ring-shaped buffer, which is a buffer with a finite length. When the buffer runs out of space, the enqueued data wraps around to the first position, overwriting the old data. Hence the name "ring-shaped".

[0066] Tracing (or logging) is an important tool for system maintenance and testing. Its complexity lies in recording the internal state of the system (i.e., the system log) into memory (or further persisting it to disk), and then using it as a key clue to trace the source of performance or functional problems. As hardware and software become more complex, tracing tools with low performance and space overhead are becoming increasingly crucial for quickly locating performance and functional issues.

[0067] In existing technologies, each core is pre-allocated a fixed amount of space to store system logs and metadata related to system logs. When the allocated space is full, new data overwrites the old data (i.e., wraparound), which leads to the following problems:

[0068] For some cores, they may be idle for a period of time, which will result in some pre-allocated space not being written to, causing space waste. For other cores, they may be busy for a period of time, which will cause historical old data to be constantly overwritten by new data, making it impossible to save very old data and resulting in low data real-time performance.

[0069] To address the aforementioned problems, embodiments of this application provide a data processing method. The data processing method of this application embodiment will be described in detail below with reference to the accompanying drawings.

[0070] Referring to FIG. 1, FIG. 1 is a flow diagram of a data processing method according to an embodiment of the present application. As shown in FIG. 1, the data processing method according to an embodiment of the present application can include steps 101-102, which will be described in detail below.

[0071] 101. When an instance of a target core writes a system log, based on the fact that the instance of the target core has insufficient space allocated for storing the system log, the instance of the target core is allocated a first space and a second space, wherein the system log is used to record a system state, the first space stores the system log, the second space stores metadata for managing the first space, and the instance of the target core exclusively uses the first space and the second space.

[0072] In the embodiment of the present application, the second space can also be described as a metadata block, and the first space can also be described as a data block.

[0073] It should be understood that, since the space can be a cache, the description of the space in the present application can also be a cache.

[0074] Instance: An instance is a software module that can run an application program or a system program, and the software module can be called an instance only when it is run by an operating system, otherwise, it is only a piece of code. An instance has various forms of expression, for example, a process, a thread, a container, etc., which can all be understood as a form of an instance. An instance runs on a node.

[0075] In the embodiment of the present application, when an instance has insufficient space allocated for storing a system log when the core actually writes data, the core is newly allocated space that can be exclusively used by the core to write the system log. That is, only when the core is busy, more space is allocated to the core, which improves the utilization of the space. The reason is that, in the worst case, assuming that there are M spaces in total and N cores, N-1 cores exclusively use a data block and no new data is generated. At this time, the space utilization rate is 1-(N-1) / M. In contrast, the space utilization rate of the prior art is 1 / N, thereby ensuring the high utilization of the space.

[0076] In addition, when the generation rates of system logs of different cores are different, the embodiment of the present application can ensure that the proportion of new data in the cache is significantly higher than that of the existing Tracing mechanism. In the extreme case, when N-1 CPUs exclusively use a block and generate extremely slow data / are blocked, the proportion of the latest data in the total cache is also 1-(N-1) / M, and the proportion of new data of other per-CPU solutions is 1 / N. Therefore, the real-time data is ensured to be high.

[0077] In addition, in the embodiments of the present application, the global queue can be divided into blocks. At runtime, the blocks are divided into different cores (there can be multiple write processes on the core), so that the instance that needs to write log on the critical path does not compete with other cores when writing log, thereby ensuring the performance scalability of Btrace and ensuring the low overhead of enqueuing.

[0078] The instance in the embodiments of the present application can be a thread. For example, the system can include but is not limited to the following functions of the thread:

[0079] The first type of thread is a trace generation (log writing) thread. There can be multiple such threads at the same time, which can concurrently produce traces into a queue.

[0080] The second type of thread is a read trace thread. There is only one thread that can read the cache at the same time, and an additional mutex (ignored in the process) is used to ensure mutual exclusivity. Generally, the second type of thread is not the first type of thread, but the patent does not make strict requirements.

[0081] The third type of thread is a thread that executes scaling instructions. There can be multiple such threads at the same time. However, only one thread can execute either of the two processes at the same time, and an additional mutex is used to ensure mutual exclusivity. Generally, the third type of thread is not the first or second type of thread, but the embodiments of the present application do not limit this.

[0082] There can be multiple threads on a core of a processor (for example, a CPU). Core x shown in FIG. 2 is a thread on the core.

[0083] In one possible implementation, a block-based global queue can be used to improve space utilization through the global queue and to avoid single-point competition through the producer's exclusive block. In addition, through metadata mapping, runtime dynamic scaling is supported. The Btrace diagram is shown in FIG. 2.

[0084] In one possible implementation, the first space and the second space belong to a plurality of spaces that are globally divided and arranged; the first variable can be read; the first variable is used to indicate the space in the plurality of spaces that is most recently allocated to the core for storing system logs; and the first space is determined according to the first variable, wherein the first space is a space in the plurality of spaces that is arranged after the space that is most recently allocated to the core for storing system logs.

[0085] In a possible implementation, the first variable includes a first global variable and a second global variable, the first global variable is used to indicate the number of spaces managed by each metadata, and the second global variable is used to indicate the number of spaces allocated for storing system logs.

[0086] To support runtime dynamic expansion and contraction, embodiments of the present application propose a metadata mapping manner to support atomic expansion and contraction. The Btrace has k (configurable) metadata blocks and N*k data blocks corresponding thereto, wherein the mapping ratio N is compressed in a global variable Ratio_and_gpos together with the position information of the latest data block. As shown in FIG. 2, there are k=4 metadata blocks in FIG. 2, and these metadata blocks manage a total of N=2, M=8 data blocks.

[0087] In a possible implementation, the metadata for managing the first space includes a second variable, and the second variable is used to indicate the round of writing data, the starting position of writing data, and the position of completed writing.

[0088] The metadata in the metadata block can be used to control / manage a data block (for example, the first space), which is identified by the high bit Rnd in the metadata. The Rnd is the wrap-around round number of the metadata block corresponding to the current managed data block position (Pos). For example, the Rnd in the metadata block used by Core1 in FIG. 2 is 1, which means that it manages the first round of Pos3, rather than the second round of Pos7.

[0089] In a possible implementation, the second space specifically stores metadata for managing the first space and a third space; based on the fact that there are other core instances currently existing, data can be written to the third space, the instance of the target core is set to exclusively use the first space, and the instances of the other cores are instructed to exit after completing data writing to the third space; and then, after the instances of the other cores exit the third space, the instance of the target core can write system logs into the first space.

[0090] Referring to FIG. 3, FIG. 3 is a flowchart of writing a Log, which includes:

[0091] Step 1: read per-CPU local saved metadata ratio_and_pos, find corresponding metadata block and data block. ratio_and_pos compresses the ratio (high bit) and pos (low bit) saved locally by the producer. At this time, the number of metadata blocks in the queue is MB_size, and the number of data blocks is DB_size = MB_size * ratio. The pos corresponds to the (pos % MB_size)th metadata block and the (pos % DB_size)th data block;

[0092] Step 2: Determine whether a wraparound has occurred by comparing the local pos round(pos / MB_size) with the metadata in the metadata block round, or when the metadata in the metadata block indicates that the current data block is full, jump to step 9, otherwise jump to step 3;

[0093] Step 3: Determine whether the remaining space can hold the current data, if so, jump to step 4, otherwise jump to step 7;

[0094] Step 4: Try to CAS metadata's allocated to reserve new space for data, is it successful? If so, go to step 5, otherwise go to step 2.

[0095] This step may fail in the following cases:

[0096] 1) Other threads under the same producer (CPU) switch and replace allocated;

[0097] 2) Other producers (including temporary producers during resizing) wrap around and overwrite allocated;

[0098] Step 5: Copy data to the reserved space. Then atomically add metadata's committed to submit data.

[0099] Step 6: Complete the enqueue and return.

[0100] Step 7: Try to CAS metadata's allocated to fill the remaining space, is it successful? If so, go to step 8, otherwise go to step 2.

[0101] Step 8: Set the size of the data header in the remaining space to 0 to represent invalid data, and atomically add metadata's committed to submit data.

[0102] Step 9: Write to current data block failed, need to push forward. Execute the pushing procedure. Then jump to step 1.

[0103] Referring to Fig. 4, Fig. 4 is a flowchart of pushing a block (i.e. allocating a new space to an instance of the core), including:

[0104] Step 1: Execute the state machine migration procedure of Resize Shrink. When not Shrink, it is just a state check;

[0105] Step 2: Get the latest ratio_and_pos by atomic fetch_add. Calculate the corresponding metadata block and the corresponding data block accordingly;

[0106] Step 3: Read the allocated of the current metadata block and save it to old_allocated;

[0107] Step 4: Determine whether there is a subsequent producer with a wrap-around by allocated. If yes, jump to step 2, otherwise jump to step 5;

[0108] Step 5: Replace allocated with the value of (current round, full) by atomic CAS. If successful, go to step 6, otherwise go to step 3; this step may fail when the subsequent producer of the next round writes allocated first and occupies this MB.

[0109] Step 6: Determine whether the previous committed is equal to the size of the data block, i.e. whether the data block is full. If yes, jump to step 9, otherwise jump to step 7;

[0110] Step 7: Set the size of the entry at the old_allocated position in the old data block to 0 to indicate that there is no valid data subsequently, and then commit the remaining space size by atomic FAA.

[0111] Step 8: Determine whether the previous committed is equal to the size of the data block, i.e. whether the data block is full. If yes, jump to step 9, otherwise jump to step 3 (corresponding to skipping).

[0112] Step 9: Replace committed in metadata block with 0 to exclusively the block, whether success. Yes, jump to step 10, otherwise jump to step 3. This step can fail when the next round producer writes committed to exclusively the block.

[0113] Step 10: Update the stamp in the head of the corresponding data block with the current pos;

[0114] Step 11: Replace allocated in metadata block with the size of data block header (including round) by CAS. Success jump to step 13, otherwise jump to step 12. This step can fail when the next round producer overwrites allocated in step 5, thus causing the setting failure.

[0115] Step 12: Set the entry size to 0 to identify no valid data in the following, and then atomically FAA commit the remaining space size. Here, because the allocated is set full in the previous step, the evicted one has no padding, and must fill it by itself. Jump to step 3.

[0116] Step 13: Replace committed in metadata block with the size of data block header (high round set to the current round) by atomically FAA. Whether the old committed is not modified. Yes, jump to step 14, otherwise jump to step 3; this step can be filled with dummy after step 11 of the next round, thus needs to be judged separately.

[0117] Step 14: Use atomic CAS to replace per_cpu's ratio_and_pos. If the scheduling goes, it can fail to set, and the data block in the data not full state will be closed by the subsequent instance for log reading / instance for log writing / resize. The process ends.

[0118] 102、The instance of the target core writes the system log into the first space.

[0119] In a possible implementation, the first variable can be updated when the number of spaces for storing the system log is expanded or reduced.

[0120] When dynamic expansion and reduction are needed, the global first variable (for example, Ratio_and_gpos in the above embodiment) can be atomically updated, so that all subsequent instances for log writing or instances for log reading can parse the data blocks and metadata blocks according to the new mapping ratio, thereby providing the space scalability.

[0121] In a possible implementation, after the first variable is updated, each instance of the core that writes or reads the system log can be evicted so that each core is aware of the updated first variable.

[0122] Referring to FIG. 5, FIG. 5 is a flowchart of extending the cache size, including:

[0123] Step 1: According to the space to be extended, a new ratio is calculated.

[0124] Step 2: The new data block is initialized, that is, the head in the data block is set to 0.

[0125] Step 3: The new pos is set, and the original pos is moved one round to discard the old misaligned data.

[0126] Step 4: The global ratio_and_pos is updated by atomic CAS, and whether it is successful is determined. If successful, go to step 5, otherwise go to step 3.

[0127] Step 5: A temporary producer is created, and the metadata block number times advancing operation is performed to evict all producers to see the latest ratio.

[0128] In a possible implementation, when the number of spaces for storing the system log is reduced, whether there is an instance that writes the system log can be determined by accessing the information for indicating the input write position in the second variable in each metadata, or when the number of spaces for storing the system log is reduced, whether there is an instance that reads the system log can be determined by accessing the third variable, where the third variable is a global variable, and the third variable is accumulated by 1 (that is, based on the timestamp) when starting to read the system log and when reading the system log is completed.

[0129] For the instance that performs log writing, whether the data block has an instance that performs log writing can be determined by the data block commit semantics, and therefore there is no need to access the counter additionally. For the instance that performs log reading, the timestamp-based method is used, and the recycling is performed only after it is ensured that all instances that perform log reading have left the read critical section.

[0130] Referring to FIG. 6, FIG. 6 is a flowchart of reading the log, including:

[0131] Step 1: The instance that performs log reading is epoch+1, and the consumer is marked to enter the read critical section.

[0132] Step 2: Get global ratio_and_pos;

[0133] Step 3: Is the pos that the instance that wants to read log greater than the pos of the instance that wants to write log? If yes, go to step 12, otherwise go to step 4; when the instance that wants to read log has gone ahead of the instance that wants to write log, there is no data to read.

[0134] Step 4: Is the pos that the instance that wants to read log covered by the latest ratio and pos? If yes, set it to the oldest pos: c.pos = pos - ratio * mb_size + 1.

[0135] Step 5: Is the committed round in the metadata block older than the round of the pos that wants to read? If yes, go to step 13, otherwise go to step 6. Because of the design of skipping, when the round in the read-out mb is older, it may be skipped, so the reading also needs to go back to check the next one.

[0136] Step 6: Is the last round of data block still read (without moving to the new pos)? If yes, go to step 7, otherwise go to step 8;

[0137] Step 7: According to the consumed recorded locally and the committed read out just now, and whether the committed and allocated are matched (need to consider the round recorded in the MB), judge whether the data has been updated. If yes, go to step 8, otherwise go to step 12. If the committed and allocated do not match, it means that it has not been committed.

[0138] Step 8: Check whether the stamp in the header of the data block is equal to the current pos? If yes, go to step 9, otherwise go to step 13;

[0139] Step 9: Read the data that has been committed at one time (read multiple at one time, when the entry is found to be 0, it needs to be discarded);

[0140] Step 10: Re-read the committed of the metadata to judge whether the data block has been overwritten by the DB (DB)? If yes, go to step 13, otherwise go to step 11; this is between the previous check (step 8 and before) and step 9, if the producer has overwritten the DB, it needs to be excluded here.

[0141] Step 11: Update the position of c.consumed as committed, and when full, c.pos+1, the instance epoch+1 to do log read, return success read data. End of flow.

[0142] Step 12: The instance epoch+1 to do log read, return no data. End of flow.

[0143] Step 13: The instance epoch+1 to do log read;

[0144] Step 14: The instance epoch+1 to do log read expects to read c.pos+1, initialize consumed. Go to Step 1.

[0145] Referring to FIG. 7, FIG. 7 is a flowchart of a process of reducing the size of the buffer, including:

[0146] Step 1: Calculate the new ratio according to the space to be reduced.

[0147] Step 2: Set the new pos, and move the original pos one round to the back to discard the old misaligned data;

[0148] Step 3: Update the global ratio_and_pos by atomic CAS, and whether it is successful. If successful, go to Step 4, otherwise go to Step 2;

[0149] Step 4: Record the epoch of the instance to do log read before resize, and set the current resize.flag

[0150] Step 5: Create a temporary producer to perform the number of metadata block advancing operations to drive all producers to see the latest ratio.

[0151] Step 6: Execute the state machine of Resize Shrink.

[0152] Referring to FIG. 8, FIG. 8 is a schematic of a recycling state machine, including:

[0153] Among them, the recycling state machine can migrate in the following 4 states. The recycling state machine is called by the thread of calling the shrink Buffer size, or the thread of generating the Trace to push the Block forward (check the corresponding state, and perform the corresponding operation).

[0154] State 0: No recycling task. When it is found that the global resize.flag is 0, it means that there is no recycling task at present, and the state is not migrated. Only when the flag is 1, migrate to state 1;

[0155] State 1: Start recovery, wait for producer. When traversing all metadata blocks, if there is no producer round that has not been updated to the latest round of eviction, do not migrate state. Otherwise, migrate to state 2.

[0156] State 2: Producer ready, wait for consumer. If the consumer epoch is odd and equal to the previously recorded epoch, do not migrate state. Otherwise, migrate to state 3.

[0157] State 3: Consumer ready, call callback. Do not migrate when callback is being called (other threads are calling the state machine at this time), otherwise migrate to state 0 when callback is completed.

[0158] In addition, in order to ensure that the queuing is not blocked, the instances in the block that are to be logged can be allowed to be submitted out of order (on the same core) and the blocks can be allowed to be pushed out of order: even if a data block is full and an instance that is to be logged has not been submitted, other instances that are to be logged on the core can simultaneously push the data block forward to avoid blocking.

[0159] Specifically, in one possible implementation, when a first instance of the target core writes a system log in a first address space of the first space and does not complete data writing, a second instance of the target core writes a system log in a second address space of the first space, which is an address space after the first address space, while skipping the first address space; or a new space other than the first space is allocated for the second instance of the target core while skipping the first address space.

[0160] Specifically, in one possible implementation, the instance of the target core can be allocated the first space based on the existence of other instances that are to be logged in a fourth space and do not complete data writing, where the fourth space is a space for storing a system log after and adjacent to the allocated space for storing a system log, and the first space is a space for storing a system log after the fourth space.

[0161] For a blocked instance that is to be logged when it is wrapped around, embodiments of the present application can allow the blocked metadata block to be closed and skipped, so as to avoid blocking the instance that is to be logged and discarding the latest data, thereby ensuring high availability of the queue. For example, in FIG. 2, Core 2 has completed writing to data block Pos4, which needs to use the metadata block occupied by Core0. However, the thread on Core0 can be blocked, causing Core2 to need to wait. Therefore, Core2 skips the metadata block, and then selects metadata block 2 (MID2) and the corresponding data block Pos6.

[0162] Referring to FIG. 9A, FIG. 9A is a schematic diagram of a system architecture or scenario applied in the present application.

[0163] FIG. 9A shows a framework of the present application. In the framework, Btrace can be integrated into an existing operating system kernel, a user state application, and the like. Specifically, Btrace can allocate a cache in memory, and threads on different cores can record logs in the reserved cache by using a log writing interface provided by an embodiment of the present application. The program executed by the thread can be an operating system kernel, a user state application framework, and a user state application program. The trace related interface can be implemented by directly linking a library implementing the method provided by an embodiment of the present application or overloading an original trace interface (such as Ftrace in the Linux kernel).

[0164] FIG. 9B shows the beneficial effects of the present application in Embodiment I. The figure shows the test of the effect of Btrace in an actual production environment. The test uses a terminal actual scene real trace record (opens the kernel scheduling related trace for performance power consumption analysis) and a post-replay manner to test the difference between Btrace and Ftrace in Linux in space utilization and data freshness (real-time continuity). Btrace and Ftrace use the same size of buffer (Ftrace is averagely allocated to each of 12 cores). The horizontal axis represents different scene traces (lock represents a lock screen), and the left horizontal axis (bar chart) is the data saved in the final trace from the latest. How many continuous traces are correctly recorded. The remaining traces are discontinuous (rewritten) and may lose critical information. The right vertical axis represents data freshness, that is, the proportion of current continuous traces in all traces read out. It can be found from the figure that in different test scenarios, Btrace can ensure that the data freshness is close to 1, that is, the data read out is the latest and continuous. The data freshness of Ftrace is unstable, especially when the use of different cores is different, and even less than 0.4 (that is, 40% of the buffer stores valid data). In addition, under the same buffer size setting, Btrace can collect 1.5-4 times longer recent and continuous data, effectively avoiding the loss of key clues and improving space utilization. In combination, under the premise of ensuring the collection of the same length of continuous traces, the memory noise of Btrace can be saved by 80%.

[0165] Referring to FIG. 10, FIG. 10 is a structural schematic of a data processing apparatus provided by an embodiment of the present application. As shown in FIG. 10, the data processing apparatus provided by an embodiment of the present application includes:

[0166] The space allocation module 1001 is configured to, when an instance of a target core writes a system log, allocate a first space and a second space for the instance of the target core based on the instance of the target core being insufficient in space allocated for storing the system log, wherein the system log is used to record a system state, the first space is used to store the system log, the second space is used to store metadata used to manage the first space, and the instance of the target core exclusively uses the first space and the second space.

[0167] The space allocation module 1001 can refer to the description of step 101 in the above embodiments, and details are not described herein.

[0168] The read-write module 1002 is configured to write the system log into the first space.

[0169] The read-write module 1002 can refer to the description of step 102 in the above embodiments, and details are not described herein.

[0170] In a possible implementation, the read-write module 1002 is further configured to:

[0171] read a first variable, wherein the first variable is used to indicate a latest space allocated for storing the system log in the plurality of spaces.

[0172] The space allocation module 1001 is further configured to determine the first space according to the first variable, wherein the first space is a space arranged after the latest space allocated for storing the system log in the plurality of spaces.

[0173] In a possible implementation, the first variable includes a first global variable and a second global variable, wherein the first global variable is used to indicate a number of spaces managed by each metadata, and the second global variable is used to indicate a number of spaces allocated for storing the system log.

[0174] In a possible implementation, the metadata used to manage the first space includes a second variable, wherein the second variable is used to indicate a round of writing data, a start position of writing data, and a position of completed writing.

[0175] In a possible implementation, the second space specifically stores metadata used to manage the first space and a third space, and the space allocation module is further configured to, based on a current existence of an instance of another core performing data writing on the third space, set the instance of the target core to exclusively use the first space, and instruct the instance of the another core to exit after completing the data writing on the third space.

[0176] The read-write module 1002 is specifically configured to:

[0177] After the instances of the other cores exit the third space, the instance of the target core writes system logs into the first space.

[0178] In a possible implementation, the space allocation module 1001 is further configured to:

[0179] The first variable is updated when the number of spaces for storing system logs is expanded or reduced.

[0180] In a possible implementation, after the first variable is updated, the space allocation module 1001 is further configured to:

[0181] Each instance of a core that writes or reads system logs is evicted, so that each core is aware of the updated first variable.

[0182] In a possible implementation, the space allocation module 1001 is further configured to:

[0183] When the number of spaces for storing system logs is reduced, it is determined whether there is an instance that writes system logs by accessing information for indicating an input write position in a second variable in each metadata; or

[0184] When the number of spaces for storing system logs is reduced, it is determined whether there is an instance that reads system logs by accessing a third variable, where the third variable is a global variable that is accumulated by 1 each time when reading system logs starts and when reading system logs is completed.

[0185] In a possible implementation, the read-write module 1002 is specifically configured to: when the first instance of the target core writes system logs in a first address space of the first space and data writing is not completed, the second instance of the target core writes system logs in a second address space of the first space by skipping the first address space, where the second address space is an address space after the first address space; or the second instance of the target core is allocated new space outside the first space by skipping the first address space.

[0186] In a possible implementation, the space allocation module 1001 is specifically configured to:

[0187] The instance of the target core is allocated the first space based on the fact that there is another instance that writes data in a fourth space and data writing is not completed, where the fourth space is a space for storing system logs after and adjacent to the already allocated space for storing system logs, and the first space is a space for storing system logs after the fourth space.

[0188] Next, a terminal device provided by an embodiment of the present application is introduced. Referring to FIG. 11, FIG. 11 is a structural schematic diagram of a terminal device provided by an embodiment of the present application. The terminal device 1100 can specifically be a virtual reality (VR) device, a mobile phone, a tablet, a notebook computer, a smart wearable device, etc., which is not limited here. Specifically, the terminal device 1100 includes a receiver 1101, a transmitter 1102, a processor 1103, and a memory 1104 (wherein the number of processors 1103 in the terminal device 1100 can be one or more, and one processor is taken as an example in FIG. 11). The processor 1103 can include an application processor 11031 and a communication processor 11032. In some embodiments of the present application, the receiver 1101, the transmitter 1102, the processor 1103, and the memory 1104 can be connected through a bus or other means.

[0189] The memory 1104 can include a read-only memory and a random access memory, and provide the processor 1103 with instructions and data. A part of the memory 1104 can also include a non-volatile random access memory (NVRAM). The memory 1104 stores processor and operation instructions, executable modules or data structures, or a subset thereof, or an expanded set thereof, wherein the operation instructions can include various operation instructions for implementing various operations.

[0190] The processor 1103 controls the operation of the device. In a specific application, various components of the device are coupled together through a bus system, which can include a data bus, a power bus, a control bus, and a state signal bus, etc. in addition to a data bus. However, for the sake of clarity, all kinds of buses are referred to as a bus system in the figure.

[0191] The method disclosed in the embodiments of the present application can be applied to the processor 1103 or implemented by the processor 1103. The processor 1103 can be an integrated circuit chip having a signal processing capability. In the implementation process, the steps of the above method can be completed by the integrated logic electric circuit or the software form instruction in the processor 1103. The processor 1103 can be a general processor, a digital signal processor (DSP), a microprocessor or a microcontroller. The processor 1103 can further include an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The processor 1103 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of the present application. The general processor can be a microprocessor or the processor can also be any conventional processor or the like. The steps of the method disclosed in combination with the embodiments of the present application can be directly embodied as a hardware code processor to execute, or be executed by a combination of hardware and software modules in the code processor. The software module can be located in a random access memory, a flash memory, a read only memory, a programmable read only memory or an electrically erasable programmable memory, a register or other mature storage medium in the art. The storage medium is located in the storage 1104, and the processor 1103 reads the information in the storage 1104 and combines the hardware to complete the steps of the data processing method in the above method.

[0192] The receiver 1101 can be used to receive input digital or character information, and generate signal input related to the relevant settings and function control of the execution device. The transmitter 1102 can be used to output digital or character information through the first interface; the transmitter 1102 can also be used to send instructions to the disk group through the first interface to modify the data in the disk group; the transmitter 1102 can also include a display device such as a display screen.

[0193] The embodiments of the present application further provide a server. Please refer to FIG. 12, which is a schematic diagram of a structure of a server provided by the embodiments of the present application. The server 1200 can be quite different due to different configurations or performances, and can include one or more central processing units (CPUs) 1212 (for example, one or more processors) and a memory 1232, one or more storage media 1230 (for example, one or more mass storage devices) for storing application programs 1242 or data 1244. The memory 1232 and the storage media 1230 can be temporary storage or persistent storage. The programs stored in the storage media 1230 can include one or more modules (not shown in the figure), and each module can include a series of instruction operations in the server. Furthermore, the central processing unit 1212 can be configured to communicate with the storage media 1230 and execute the series of instruction operations in the storage media 1230 on the server 1200.

[0194] The server 1200 can further include one or more power supplies 1226, one or more wired or wireless network interfaces 1250, one or more input / output interfaces 1258, or one or more operating systems 1241, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0195] In the embodiments of the present application, the central processing unit 1212 is configured to perform the actions related to model training or model inference in the above embodiments.

[0196] The embodiments of the present application further provide a computer program product, which, when running on a computer, enables the computer to perform the steps of the data processing method in the above method.

[0197] The embodiments of the present application further provide a computer readable storage medium, which stores a program for signal processing, and when the program runs on a computer, enables the computer to perform the steps performed by the above execution device, or enables the computer to perform the steps performed by the above training device.

[0198] The execution device, the training device or the terminal device provided in the embodiments of the present application can specifically be a chip, which comprises a processing unit, for example, a processor, and a communication unit, for example, an input / output interface, a pin or a circuit, etc. The processing unit can execute computer execution instructions stored in a storage unit, so that the chip in the execution device executes the data processing method described in the above embodiments, or so that the chip in the training device executes the data processing method described in the above embodiments. Alternatively, the storage unit is a storage unit in the chip, such as a register, a cache, etc., and the storage unit can also be a storage unit outside the chip in the wireless access device, such as a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM), etc.

[0199] In addition, it should be noted that the apparatus embodiments described above are merely illustrative, wherein the units described as separate components can or can not be physically separated, and the components displayed as units can or can not be physical units, i.e., they can be located in one place or distributed on multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiments of the present application. In addition, in the apparatus embodiments provided in the present application, the connection relationship between the modules indicates that there is a communication connection between them, which can be implemented as one or more communication buses or signal lines.

[0200] Through the description of the above embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software and necessary general hardware, and of course, it can also be implemented by special hardware including special integrated circuits, special CPUs, special memories, special components, etc. Generally, functions completed by computer programs can be easily implemented by corresponding hardware, and specific hardware structures for implementing the same function can also be various, such as analog circuits, digital circuits or special circuits, etc. However, for the present application, software program implementation is a better embodiment. Based on this understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer floppy disk, U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk, etc., including a plurality of instructions to make a computer device (which can be a personal computer, a training device or a network device, etc.) execute the methods described in the embodiments of the present application.

[0201] In the above embodiments, the implementation can be wholly or partially by software, hardware, firmware, or any combination thereof. When implemented by software, the implementation can be wholly or partially in the form of a computer program product.

[0202] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are wholly or partially generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another, for example, the computer instructions can be transmitted from one website, computer, training device or data center to another website, computer, training device or data center through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a training device, a data center, etc. integrated with one or more available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk (SSD)), etc.

Claims

1. A data processing method, characterized by, The method comprises: allocating a first space and a second space for an instance of a target core based on that the instance of the target core has insufficient space allocated for storing system logs, wherein the system logs are used to record system states, the first space is used to store system logs, the second space is used to store metadata for managing the first space, and the instance of the target core exclusively uses the first space and the second space; the instance of the target core writes system logs into the first space.

2. The method of claim 1, wherein, The first space and the second space belong to a plurality of spaces which are globally divided and arranged; the method further comprises: reading a first variable; the first variable is used to indicate a latest space allocated for storing system logs among the plurality of spaces; determining the first space according to the first variable, wherein the first space is a space arranged after the latest space allocated for storing system logs among the plurality of spaces.

3. The method of claim 2, wherein, The first variable comprises a first global variable and a second global variable, the first global variable is used to indicate a number of spaces managed by each metadata, and the second global variable is used to indicate a number of allocated spaces for storing system logs.

4. The method according to any one of claims 1 to 3, characterized in that, The metadata for managing the first space comprises a second variable; the second variable is used to indicate a round of writing data, a starting position of writing data, and a position of completed writing.

5. The method of claim 4, wherein, The second space specifically stores metadata for managing the first space and a third space; the method further comprises: based on a current existence of other instances of cores writing data into the third space, setting the instance of the target core to exclusively use the first space, and instructing the other instances of the cores to exit after completing writing data into the third space; the instance of the target core writes system logs into the first space, comprising: after the other instances of the cores exit the third space, the instance of the target core writes system logs into the first space.

6. The method according to any one of claims 3 to 5, characterized in that, The method further comprises: updating the first variable when the number of spaces for storing system logs expands or shrinks.

7. The method of claim 6, wherein, After updating the first variable, the method further comprises: evicting each instance of a core writing or reading system logs, so that each core is aware of the updated first variable.

8. The method according to any one of claims 1 to 7, characterized in that, The method further comprises: when the number of spaces for storing system logs shrinks, determining whether there is an instance writing system logs by accessing information indicating an input writing position in the second variable in each metadata; or when the number of spaces for storing system logs shrinks, determining whether there is an instance reading system logs by accessing a third variable, wherein the third variable is a global variable which is accumulated by 1 each time when starting to read system logs and when finishing reading system logs.

9. The method according to any one of claims 1 to 8, characterized in that, The instance of the target core writes the system log into the first space, including: when a first instance of the target core writes the system log into a first address space of the first space and does not complete data writing, a second instance of the target core writes the system log into a second address space of the first space, the second address space being an address space after the first address space; or, a new space outside the first space is allocated for the second instance of the target core to skip the first address space.

10. The method according to any one of claims 1 to 9, characterized in that, The first space is allocated for the instance of the target core, including: The first space is allocated for the instance of the target core based on the existence of data writing and incomplete data writing of other instances to a fourth space, wherein the fourth space is a space for storing system logs after and adjacent to the allocated space for storing system logs, and the first space is a space for storing system logs after the fourth space.

11. A data processing apparatus, characterized by, The device includes: The space allocation module is configured to allocate a first space and a second space for an instance of a target core based on an insufficient space for storing system logs allocated for the instance of the target core when the instance of the target core writes the system log, wherein the system log is used to record a system state, the first space stores the system log, the second space stores metadata for managing the first space, and the instance of the target core exclusively uses the first space and the second space; The read-write module is configured to write the system log into the first space.

12. The apparatus of claim 11, wherein, The read-write module is further configured to: read a first variable; the first variable is used to indicate a latest space for storing system logs allocated for a core in the plurality of spaces; The space allocation module is further configured to determine the first space according to the first variable, wherein the first space is a space arranged after the latest space for storing system logs allocated for the core in the plurality of spaces.

13. The apparatus of claim 12, wherein, The first variable includes a first global variable and a second global variable, the first global variable is used to indicate a number of spaces managed by each metadata, and the second global variable is used to indicate a number of allocated spaces for storing system logs.

14. The apparatus of any one of claims 11 to 13, wherein, The metadata for managing the first space includes a second variable; the second variable is used to indicate a round of writing data, a starting position of writing data, and a position of completed writing.

15. The apparatus of claim 14, wherein, The second space specifically stores metadata for managing the first space and a third space; the space allocation module is further configured to set the instance of the target core to exclusively use the first space and instruct other instances of cores to exit after completing data writing to the third space based on the current existence of data writing to the third space by the other instances of the cores; The read-write module is specifically configured to: write the system log into the first space after the other instances of the cores exit the third space.

16. The apparatus of any one of claims 13 to 15, wherein, The space allocation module is further configured to: The first variable is updated when the amount of space for storing system logs is expanded or reduced.

17. The apparatus of claim 16, wherein, After the first variable is updated, the space allocation module is further configured to: evict each instance of a core writing or reading system logs so that each core is aware of the updated first variable.

18. The apparatus of any one of claims 11 to 17, wherein, The space allocation module is further configured to: determine whether there is an instance of writing system logs by accessing information indicating an input write position in a second variable in each metadata when the amount of space for storing system logs is reduced; or determine whether there is an instance of reading system logs by accessing a third variable when the amount of space for storing system logs is reduced, wherein the third variable is a global variable that is incremented by 1 each time reading system logs is started and completed.

19. The apparatus of any of claims 11 to 18, wherein, The read-write module is specifically configured to: when the first instance of the target core writes system logs in a first address space of the first space and data writing is not completed, a second instance of the target core writes system logs in a second address space of the first space by skipping the first address space, the second address space being an address space after the first address space; or allocate a new space other than the first space for the second instance of the target core to skip the first address space.

20. The apparatus of any one of claims 11 to 19, wherein, The space allocation module is specifically configured to: based on the existence of data writing to a fourth space by other instances and the fact that data writing is not completed, allocate the first space for the instance of the target core, wherein the fourth space is a space for storing system logs after and adjacent to the already allocated space for storing system logs, and the first space is a space for storing system logs after the fourth space.

21. A computer storage medium, comprising, The computer storage medium stores one or more instructions, which, when executed by one or more computers, cause the one or more computers to perform the operations of the method of any one of claims 1-10.

22. A computer program product, characterised in that, The computer storage medium stores one or more instructions, which, when executed by one or more computers, cause the one or more computers to perform the operations of the method of any one of claims 1-10.

23. A system comprising at least one processor, at least one memory; the processor, the memory are connected through a communication bus and complete communication with each other; The at least one memory is configured to store code; The at least one processor is configured to execute the code to perform the method of any one of claims 1-10.

24. A chip comprising a processor, wherein: The processor is configured to support a data processing apparatus to implement the method of any one of claims 1-10. The processor is configured to support a data processing apparatus to implement the method of any one of claims 1-10.

Images