System call implementation method and related device

Abstract

The invention discloses a system call implementation method, which is used for reducing the time overhead for executing system call by an application program. In the implementation method for system calling, a plurality of codes of different versions are provided for system services for realizing system functions, and different codes can provide the same system functions during execution and provide irrelevant functions under different conditions, so that when a process calls the system services, the system functions of the system can be called, and the system functions of the system can be realized. And selecting a corresponding code for the process to execute according to a pre-specified corresponding relationship between the process and the code. Therefore, during the execution of the system call, the corresponding irrelevant functions can be selectively provided according to the actual condition of the process, and the condition that all irrelevant functions are provided when the system call is executed for the process is avoided, so that the time overhead for executing the system call by the application program is effectively reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and in particular, to a system call implementation method and related device. BACKGROUND

[0002] In a computer, an application program usually runs in a user state, and a kernel of an operating system runs in a kernel state. When the application program needs to use some functions provided by the operating system (such as reading and writing files, sending and receiving network data, and allocating memory), the application program needs to interact with the kernel through a system call, so as to call the functions provided by the operating system.

[0003] When the application program calls the functions provided by the operating system through the system call, the processor is usually switched from the user state to the kernel state, and a system call function provided in the kernel is executed, so as to provide the corresponding functions to the application program. Therefore, compared with a function call in the application program, the time cost of executing the system call is usually higher.

[0004] In most business scenarios, the application program usually frequently executes the system call. Since the time cost of executing the system call is high, in the scenario where the application program frequently executes the system call, the running performance of the application program is usually greatly affected. Therefore, how to reduce the time cost of the application program executing the system call has become a problem to be solved. SUMMARY

[0005] The present application provides a system call implementation method, which can effectively reduce the time cost of the application program executing the system call.

[0006] The present application provides a system call implementation method, which can effectively reduce the time cost of the application program executing the system call.

[0007] Then, based on a pre-established correspondence between the first process and the first target code, the first target code is selected from a plurality of codes to execute, so as to provide the first system service to the first process. The plurality of codes are all used to implement the first system service, and the plurality of codes provide different unrelated functions when executed. The unrelated function is a function that is not required to be dependent when the first system service is implemented. Therefore, even if the unrelated function is not provided, it actually does not affect the normal provision of the system function called by the first process to the first process.

[0008] In the scheme, by providing multiple different versions of codes for system services for realizing system functions, the different codes can provide the same system functions when executed and the cases of providing irrelevant functions are not the same, so that when a process calls a system service, the corresponding code can be selected for the process according to the pre-specified correspondence between the process and the code to execute. In this way, during the execution of the system call, the corresponding irrelevant functions can be selectively provided according to the actual situation of the process, avoiding providing all irrelevant functions when the process executes the system call, thereby effectively reducing the time overhead of the application program executing the system call.

[0009] In a possible implementation, in order to establish the correspondence between the first process and the code in the multiple codes, the calling information of the first process for the first system service is acquired, and the calling information includes at least one of the frequency of the first process calling the first system service, the execution time of the first system service, the number of blocking times when the first process calls the first system service, and the number of preemption times.

[0010] Then, based on the calling information, the first target code is determined in the multiple codes to provide the first system service for the first process, so as to establish the correspondence between the first process and the first target code. That is, the kernel determines the code version of the system call corresponding to the process based on the collected behavior information of the process executing the system call.

[0011] In the scheme, by collecting the system call behavior of the process, the specific execution situation of the process for a type of system call can be obtained, so that the most matched system call code is selected for the process in the multiple codes, thereby being able to improve the efficiency of the process executing the system call while ensuring the normal operation of the operating system as much as possible.

[0012] In a possible implementation, the first system call request includes a system call number corresponding to the first system service and a process number corresponding to the first process. Based on the system call number and the process number in the first system call request, the code address corresponding to the system call number can be queried in the private system call table corresponding to the process number to obtain the address of the first target code. After obtaining the address of the first target code, the address of the first target code is jumped to to execute the first target code. By executing the first target code, the system function can be provided for the first process, thereby completing the process of the system call.

[0013] In the scheme, by setting the private system call table for the process, the corresponding relationship between the system call number and the code address is recorded, which can quickly determine which code to use to provide the system call corresponding system function for the current process based on the process number and the system call number, which is beneficial to quickly determine the corresponding code of the process in multiple codes providing the same system function, and further to select the most suitable system call code version for the process.

[0014] In a possible implementation, during the period when the first process does not call the first system service, the code address corresponding to the system call number in the private system call table is configured as the address of the first target code. In order to avoid errors during the execution of the system call, the kernel needs to ensure that the code address corresponding to the system call number of the first system service is configured during the period when the first process does not call the first system service.

[0015] In the scheme, by setting the private system call table for the process, the corresponding relationship between the system call number and the code address is recorded, which can quickly determine which code to use to provide the system call corresponding system function for the current process based on the process number and the system call number, which is beneficial to quickly determine the corresponding code of the process in multiple codes providing the same system function, and further to select the most suitable system call code version for the process.

[0016] In a possible implementation, the kernel obtains a configuration instruction, which is used to indicate that the code address corresponding to the system call number in the private system call table is configured as the address of the first target code. Based on the configuration instruction, the kernel triggers the configuration of the code address corresponding to the system call number in the private system call table as the address of the first target code. That is, the kernel configures the corresponding code address in the private system call table based on the obtained configuration instruction.

[0017] In the scheme, by selecting the corresponding system call code for the process in multiple codes based on the obtained configuration instruction, the system call code version corresponding to the process can be configured or adjusted based on the user's demand, thereby meeting the diversified needs of the user for the process running.

[0018] In a possible implementation, before the kernel configures the code address corresponding to the system call number of the first process as the address of the first target code, the running of the first process is first suspended; and after the configuration of the code address corresponding to the system call number of the first process is completed, the running of the first process is resumed.

[0019] In this way, by suspending the running of the first process during the configuration of the code address corresponding to the system call number, it can be ensured that the first process will not trigger a system call during this period, thereby avoiding the problem of system call error due to unsuccessful configuration of the code address corresponding to the system call number.

[0020] In a possible implementation, before executing the first target code, the kernel determines the size of the hardware context, specifically the values of registers, to be saved based on the type of the first system service provided by the first target code. Then, the saving of the hardware context is performed based on the size of the hardware context. The saved hardware context is used to restore after the execution of the first target code.

[0021] That is, after the process triggers the call of the system service, the size of the hardware context to be saved is determined based on the type of the system service called by the process, so that the saved hardware context is all the hardware context that will be changed during the execution of the system service, and the saving of all the hardware context corresponding to the process is avoided.

[0022] In the scheme, the size of the hardware context to be actually saved is determined based on the type of the system service triggered by the process, so that the saved hardware context can be reduced as much as possible in actual application, and the efficiency of the process in executing the system call is improved without affecting the normal operation of the process.

[0023] In a possible implementation, the kernel can obtain a second system call request from a second process, and the second system call request is used to request the call of the first system service. Based on the correspondence between the second process and the second target code, the kernel selects the second target code from the plurality of codes for implementing the first system service to execute, so as to provide the first system service to the second process.

[0024] In the scheme, for the same system service, different processes are set to use different code versions for implementation, so that the most suitable system call code version is selected for the process based on the business characteristics of the process itself, thereby meeting the diversified needs of the process under various business characteristics.

[0025] In a possible implementation, in a case where the frequency of the call of the first system service by the first process is greater than a first threshold value and the execution time of the first system service is less than a second threshold value, the first target code is a code that does not provide irrelevant functions in the plurality of codes; or in a case where the number of preemptions when the first process calls the first system service is greater than a third threshold value, the irrelevant functions provided by the first target code only include security enhancement functions; or in a case where the number of blockings when the first process calls the first system service is greater than a fourth threshold value, the irrelevant functions provided by the first target code only include scheduling functions and maintenance functions.

[0026] In a possible implementation, the plurality of codes comprises a first code, a second code and a third code, the first code is configured to provide all irrelevant functions included in the irrelevant function set when executed, the second code is configured to provide part of the irrelevant functions in the irrelevant function set when executed, and the third code is not configured to provide the irrelevant functions in the irrelevant function set when executed.

[0027] The second aspect of the present application provides an implementation device of a system call, comprising: an obtaining module configured to obtain a first system call request from a first process, the first system call request being configured to request to call a first system service; and a processing module configured to select a first target code from a plurality of codes based on a correspondence between the first process and the first target code, so as to execute the first target code to provide the first system service to the first process, wherein the plurality of codes are all configured to implement the first system service, and the plurality of codes provide irrelevant functions in different cases when executed, and the irrelevant functions are functions that are not required to be dependent when the first system service is implemented.

[0028] In a possible implementation, the obtaining module is further configured to obtain call information of the first process for the first system service, and the call information comprises at least one of a frequency of the first process calling the first system service, an execution time of the first system service, a number of times of blocking when the first process calls the first system service, and a number of times of being pre-empted; and the processing module is further configured to determine, based on the call information, that the first target code is used to provide the first system service to the first process from the plurality of codes, so as to establish the correspondence between the first process and the first target code.

[0029] In a possible implementation, the first system call request comprises a system call number corresponding to the first system service and a process number corresponding to the first process; and the processing module is specifically configured to: query, in a private system call table corresponding to the process number, a code address corresponding to the system call number, so as to obtain an address of the first target code; and jump to the address of the first target code to execute the first target code.

[0030] In a possible implementation, the processing module is further configured to: during a period when the first process does not call the first system service, configure, in the private system call table, the code address corresponding to the system call number as the address of the first target code.

[0031] In a possible implementation, the obtaining module is further configured to obtain a configuration instruction, the configuration instruction being configured to indicate to configure, in the private system call table, the code address corresponding to the system call number as the address of the first target code; and the processing module is further configured to trigger, based on the configuration instruction, the configuration, in the private system call table, of the code address corresponding to the system call number as the address of the first target code.

[0032] In a possible implementation, the processing module is further configured to: suspend running of the first process before the code address corresponding to the system call number is configured as the address of the first target code; and resume running of the first process after the configuration of the code address corresponding to the system call number is completed.

[0033] In a possible implementation, before the first target code is executed, the processing module is further configured to: determine a size of hardware context that needs to be saved based on a type of the first system service provided by the first target code, the hardware context being values of registers; and perform saving of the hardware context based on the size of the hardware context; wherein the saved hardware context is used to restore after the first target code is executed.

[0034] In a possible implementation, the obtaining module is further configured to obtain a second system call request from a second process, the second system call request being used to request calling of the first system service; and the processing module is further configured to select the second target code from the plurality of codes to execute, based on a correspondence between the second process and the second target code, to provide the first system service to the second process.

[0035] In a possible implementation, in a case where a frequency of calling the first system service by the first process is greater than a first threshold value and an execution time of the first system service is less than a second threshold value, the first target code is a code that does not provide irrelevant functions from the plurality of codes; or in a case where a number of preemptions when the first process calls the first system service is greater than a third threshold value, the irrelevant functions provided by the first target code only include security enhancement functions; or in a case where a number of blockings when the first process calls the first system service is greater than a fourth threshold value, the irrelevant functions provided by the first target code only include scheduling functions and measurement functions.

[0036] In a possible implementation, the plurality of codes includes a first code, a second code, and a third code, the first code is used to provide all irrelevant functions included in a set of irrelevant functions when the first code is executed, the second code is used to provide part of the irrelevant functions in the set of irrelevant functions when the second code is executed, and the third code is not used to provide the irrelevant functions in the set of irrelevant functions when the third code is executed.

[0037] The third aspect of the present application provides an implementation device of a system call, which can include a processor, the processor is coupled with a memory, and the memory stores program instructions, which, when executed by the processor, implement the method of the first aspect or any implementation manner of the first aspect. For the steps of the processor executing each possible implementation manner of the first aspect, specific details can be referred to the first aspect, which will not be described here.

[0038] The fourth aspect 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 program causes the computer to execute the method of any of the implementation manners of the first aspect.

[0039] The fifth aspect of the present application provides a circuit system, which comprises a processing circuit configured to execute the method of any of the implementation manners of the first aspect.

[0040] The sixth aspect of the present application provides a computer program product, which causes a computer to execute the method of any of the implementation manners of the first aspect when the computer program product is run on the computer.

[0041] The seventh aspect of the present application provides a chip system, which comprises a processor configured to support a server to implement the functions involved in any of the implementation manners of the first aspect, for example, to process the data and / or information involved in the method. In a possible design, the chip system further comprises a memory configured to store necessary program instructions and data of the server. The chip system can be composed of a chip, or can comprise the chip and other discrete devices.

[0042] The advantages of the second aspect to the seventh aspect can refer to the introduction of the first aspect, and will not be described herein. BRIEF DESCRIPTION OF DRAWINGS

[0043] Figure 1 A schematic diagram of a system architecture provided by the present application is shown in FIG. 1;

[0044] Figure 2 A structural schematic diagram of an execution device 101 provided by the present application is shown in FIG. 2;

[0045] Figure 3 A flowchart of an implementation method of a system call provided by the present application is shown in FIG. 3;

[0046] Figure 4 A schematic diagram of a system architecture provided by the present application is shown in FIG. 1;

[0047] Figure 5 A schematic diagram of another system architecture provided by the present application is shown in FIG. 4;

[0048] Figure 6 A working flowchart of a privilege level switcher provided by the present application is shown in FIG. 5;

[0049] Figure 7 A working flowchart of a system call offloader provided by the present application is shown in FIG. 6;

[0050] Figure 8 A working flowchart of a system call configurator provided by the present application is shown in FIG. 7;

[0051] Figure 9 A workflow schematic diagram of a system call filter provided by the present application;

[0052] Figure 10 An implementation flow schematic diagram of a native Futex system call provided by the present application;

[0053] Figure 11 A system architecture schematic diagram for improving database service performance provided by the present application;

[0054] Figure 12 An optimization flow schematic diagram for a database query thread provided by the present application;

[0055] Figure 13 An optimization flow schematic diagram for a network worker thread provided by the present application;

[0056] Figure 14 A structure schematic diagram of an implementation device of a system call provided by the present application;

[0057] Figure 15 A structure schematic diagram of an electronic device provided by the present application;

[0058] Figure 16 A structure schematic diagram of a computer readable storage medium provided by the present application. DETAILED DESCRIPTION

[0059] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, not all the embodiments of the present application.

[0060] The terms "first", "second", "third", "fourth" and the like (if any) in the specification and claims of the present application and the above 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 data thus used can be interchanged under appropriate circumstances, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein.

[0061] In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a list of steps or units does not necessarily limit to those clearly listed steps or units, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0062] In order to facilitate understanding, some technical terms related to the embodiments of the present application will be introduced first.

[0063] (1) System call

[0064] A system call is a mechanism provided by an operating system to an application program to request kernel services. In essence, a system call is a programming interface provided by an operating system to an application program, allowing the application program to interact with the kernel of the operating system to access the services and resources provided by the operating system. System calls are part of the operating system kernel, through which an application program can perform some privileged operations, such as file access, process management, and network communication.

[0065] (2) System service

[0066] A system service refers to a program, routine, or process that performs a specified system function to support other programs to obtain system functions. In a microkernel system, a system service is usually responsible for providing a specific function (such as process management, memory management, file system, device driver, network protocol, etc.). Specifically, when an application program triggers a system call, it is actually calling a system service to obtain a system function to facilitate functions such as reading and writing files, sending and receiving network data, and allocating memory.

[0067] (3) Exception trap

[0068] In order for an application program to execute a system call, the processor provides an instruction for the application program to trigger an exception trap. By executing this instruction, the processor triggers an exception trap, which switches from user mode to kernel mode. Then, the processor starts executing from the system call function provided by the kernel to implement the system function provided by the kernel.

[0069] (4) Kernel mode

[0070] Kernel mode refers to the state of the operating system's management program when it is running, with a high privilege level. Specifically, the kernel of the operating system runs in kernel mode and can access the computer's task resources, i.e., the kernel's resource access permissions are not restricted.

[0071] (5) User mode

[0072] User mode refers to the state of an application program when it is running, with a low privilege level. Specifically, the resources accessed by an application program running in user mode are usually restricted. For example, the operating system kernel running in kernel mode can directly access the hard disk and network card. Application programs running in user mode must rely on the operating system's kernel to operate hardware devices, such as text editors reading and writing files, and web browsers accessing the Internet.

[0073] (6) Kernel

[0074] The kernel is the most basic part of the operating system, and is essentially a piece of software that provides safe access to the computer hardware for numerous applications. The kernel can provide the most basic functions of the operating system, and is the basis for the operation of the operating system.

[0075] (7) Process

[0076] A process is a running activity of a program on a certain data set in a computer, is a basic unit of resource allocation of a system, and is the basis of the structure of an operating system. In the early process-oriented computer structure, the process is the basic execution entity of the program; in the contemporary thread-oriented computer structure, the process is a container of threads. An application program refers to the description of instructions, data and their organization form, and a process is a one-time execution process of an application program.

[0077] (8) Thread

[0078] A thread is the smallest unit of operation scheduling that can be performed by an operating system. A thread is contained in a process and is the actual operating unit in the process. A thread refers to a single sequential control flow in a process. Multiple threads can be concurrently executed in a process, each thread performing different tasks in parallel.

[0079] (9) Hardware context

[0080] The hardware context usually refers to the running state of an application program. The running state of an application program is usually saved in a set of registers of a processor, and therefore the hardware context often refers to the values of the registers used to store the running state of the application program.

[0081] In most business scenarios, an application program usually frequently executes system calls. Since the time overhead of executing a system call is high, the running performance of the application program is often greatly affected in the scenario where the application program frequently executes system calls.

[0082] The applicant found that when the kernel processes various system call requests from an application program, the kernel often executes other function-related processes in addition to the relevant processes corresponding to the functions called by the application program itself, in order to provide security enhancement functions, process scheduling functions, maintenance test functions and other functions unrelated to the functions called by the application program itself during system call execution. In this way, in the scenario where the application program frequently executes system calls, the kernel often wastes a lot of time to implement other unrelated functions, resulting in large time overhead of system calls, which easily affects the normal execution of the application program.

[0083] Therefore, the application provides a system call implementation method. By providing multiple different versions of codes for system services implementing system functions, the different codes can provide the same system functions when executed and the unrelated functions are different. When a process calls a system service, the corresponding code is selected for the process according to the pre-specified correspondence between the process and the code. In this way, during the execution of the system call, the corresponding unrelated functions can be selectively provided according to the actual situation of the process, avoiding providing all the unrelated functions when the process executes the system call, thereby effectively reducing the time overhead of the application program executing the system call.

[0084] Referring to Figure 1 , Figure 1 a system architecture provided by the application is shown. As Figure 1 shown, in the system architecture, the execution device 101 can be a physical host or a physical server, etc. The execution device 101 is in communication connection with the data storage system 102, for obtaining the program code stored in the data storage system 102, to implement the system call implementation method provided by the application. The data storage system 102 can be implemented by a storage device deployed on the execution device 101, for example, the execution device 101 is a physical server, and the data storage system 102 is a hard disk deployed on the physical server. The data storage system 102 can also be implemented by a storage device independent of the execution device, for example, the execution device 101 is a computing server, and the data storage system 102 is a data server specially storing program codes.

[0085] During the work, the execution device 101 can obtain the program code and related data required for the system call implementation method from the data storage system 102, and provide the efficiency of the thread calling the system service on the execution device 101 based on the system call implementation method provided by the application.

[0086] Referring to Figure 2 , Figure 2 a structure diagram of the execution device 101 provided by the application is shown. As Figure 2As shown, the execution device 101 to which the implementation method of the system call provided by the present application is applied includes a processor 103, which is coupled with a system bus 105. The processor 103 can be one or more processors, each of which can include one or more processor cores. A video adapter 107 can drive a display 109, which is coupled with the system bus 105. The system bus 105 is coupled with a bus bridge 111 and an input / output (I / O) bus. An I / O interface 115 is coupled with the I / O bus. The I / O interface 115 communicates with various I / O devices, such as an input device 117 (e.g., a touch screen), an external storage 121 (e.g., a hard disk, a floppy disk, an optical disk, or a USB (Universal Serial Bus) drive), a multimedia interface, etc.), a transceiver 123 (which can send and / or receive radio communication signals), a camera 155 (which can capture still and moving digital images), and an external USB port 125. Among them, the interface connected with the I / O interface 115 can be a USB interface, optionally.

[0087] The processor 103 can be any conventional processor, including a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, or a combination thereof. Optionally, the processor can be a special-purpose device such as an ASIC.

[0088] The execution device 101 can communicate with a software deployment server 149 through a network interface 129. The network interface 129 is an example of a hardware network interface, such as a network card. The network 127 can be an external network such as the Internet, or an internal network such as an Ethernet network or a virtual private network (VPN). Optionally, the network 127 can also be a wireless network such as a WiFi network, a cellular network, etc.

[0089] A hard drive interface 131 is coupled with the system bus 105. The hard drive interface is connected with a hard disk drive 133. A system memory 135 is coupled with the system bus 105. The data running in the system memory 135 can include an operating system (OS) 137 of the execution device 101, an application program 143, and a schedule.

[0090] The operating system includes a shell 139 and a kernel 141. The shell 139 is an interface between a user and the kernel of the operating system. The shell is the outermost layer of the operating system. The shell manages the interaction between the user and the operating system: waits for the user's input, interprets the user's input to the operating system, and processes various outputs of the operating system.

[0091] The kernel 141 consists of those parts of the operating system that are used to manage memory, files, peripherals, and system resources. The kernel 141 directly interacts with the hardware, and the operating system kernel usually runs processes and provides inter-process communication, provides CPU time slice management, interrupts, memory management, and IO management, etc.

[0092] Referring to Figure 3 , Figure 3 A flowchart of an implementation method of a system call provided in the present application is shown. As Figure 3 shown, the implementation method of the system call can be applied to the kernel in the operating system, and specifically includes the following steps 301-302.

[0093] Step 301, obtaining a first system call request from a first process, the first system call request being used to request to call a first system service.

[0094] In the present application, during the running of the first process, when the first process needs to use the system function provided by the operating system, the first process can send a first system call request to the kernel, so as to obtain the system function provided by the operating system in the form of a system call. Specifically, the first system call request can be used to request to call a first system service, and the first system service, when implemented, can provide the first process with the system function requested by the first process. That is, the first system service can be understood as an execution entity for providing a specified system function, and by calling the first system service, the specified system function can be provided for the first process.

[0095] For example, the first system service can be used to provide functions such as reading and writing files, transmitting network data, allocating memory, process management, exception management, memory mapping management, and inter-process communication, and the present application does not make specific limitations on the system function provided by the first system service.

[0096] It should be noted that the first system call request can be sent by any thread in the first process to the kernel. Moreover, since the first system call request usually carries a process number, the kernel can determine which process the first system call request comes from based on the process number carried in the first system call request.

[0097] At step 302, based on the correspondence between the first process and the first target code, the first target code is selected from the plurality of codes to execute to provide the first system service to the first process; wherein the plurality of codes are all used to implement the first system service, and the plurality of codes provide different irrelevant functions when executed.

[0098] In the present application, the correspondence between the first process and the first target code used to provide the first system service is established in the kernel. Moreover, the plurality of codes are all used to provide the first system service, and the first process only has the correspondence with the first target code in the plurality of codes. In this way, when the kernel obtains the first system call request from the first process, the kernel selects the first target code from the plurality of codes used to provide the first system service to execute, so as to provide the first system service to the first process by executing the first target code.

[0099] It should be noted that the plurality of codes can all be used to provide the first system service, and the plurality of codes provide different irrelevant functions when executed. Therefore, the time consumption of the plurality of codes when executed is different. That is, the combination of the irrelevant functions provided by different codes in the plurality of codes when executed is different.

[0100] In the present application, the irrelevant function refers to other functions irrelevant to the system function called by the first process. That is, the irrelevant function is a function that is not required to be dependent when implementing the first system service used to provide the system function. Therefore, even if the irrelevant function is not provided, it will not actually affect the normal provision of the system function called by the first process to the first process.

[0101] For example, the plurality of codes used to implement the first system service can include a first code, a second code and a third code. The first code is used to provide all irrelevant functions in the irrelevant function set when executed, the second code is used to provide part of the irrelevant functions in the irrelevant function set when executed, and the third code is not used to provide the irrelevant functions in the irrelevant function set when executed.

[0102] The irrelevant functions included in the irrelevant function set can include all irrelevant functions provided when a system call is executed in an existing operating system, such as security enhancement functions, process scheduling functions, maintenance test functions, and signal processing functions. Therefore, the first code can be understood as a native code (i.e., a native system call code version) related to a system call provided by an existing operating system. The second code and the third code can be understood as customized code versions in which irrelevant functions are reduced based on the native system call code version. Generally, the irrelevant functions are functions set by an existing operating system for other purposes when a system call is executed. The irrelevant functions are irrelevant to the system functions called by a process, and canceling the irrelevant functions does not affect the normal implementation of the system functions called by the process.

[0103] For example, the security enhancement functions are mainly used to protect sensitive data in the kernel, and prevent a process from obtaining the sensitive data through a system call. The process scheduling functions are used to periodically switch the running processes on the processor, so as to implement simultaneous processing of multiple processes on the processor within a period of time, and avoid long response time of some processes. The maintenance test functions are used to implement maintenance and testing of an application itself, and need to notify a debugging program of a monitoring process when a system call is completed. The signal processing functions are used to notify a process of an asynchronous event.

[0104] Since the irrelevant functions are irrelevant to the system functions called by a process, and canceling the irrelevant functions does not affect the normal implementation of the system functions called by the process, in most cases, the irrelevant functions that need to be retained and the irrelevant functions that can be removed when a process executes a system call can be determined according to the specific situation of the process executing the system call, so as to minimize the irrelevant functions that need to be executed by the process during execution of the system call.

[0105] It should be noted that the multiple codes including the first code, the second code, and the third code are only one possible example provided by the present application, and in actual cases, the irrelevant functions provided by each code in the multiple codes can be set according to the characteristics of the system call, which is not limited in the present application. That is, the irrelevant functions provided when the multiple codes are executed can be related to the type of the first system service.

[0106] For example, when the first system service involves access to sensitive data in the kernel, the irrelevant functions provided by each code in the multiple codes can include security enhancement functions, and the irrelevant functions provided by each code in the multiple codes can be different.

[0107] The above describes the process of selecting the first target code for the first process to implement the first system service when the first process calls the first system service. In actual applications, when different processes call the same system service, different codes can be selected for different processes to implement the same system service based on the correspondence between the processes and the codes, so as to select the most appropriate system call code version for various types of processes.

[0108] For example, the kernel can obtain a second system call request from a second process, and the second system call request is used to request to call the first system service. Based on the correspondence between the second process and the second target code, the kernel selects the second target code from the multiple codes for implementing the first system service to execute, so as to provide the first system service to the second process.

[0109] That is, for the first system service, when the first process calls the first system service, the kernel selects the first target code to provide the first system service for the first process; when the second process calls the first system service, the kernel selects the second target code to provide the first system service for the first process. That is, the system call code version corresponding to the process is related to the business characteristics of the process itself. Processes with different business characteristics often correspond to different system call code versions, so as to ensure that the most appropriate system call code version is matched for each process.

[0110] In this scheme, for the same system service, different processes are configured to use different code versions, which can select the most appropriate system call code version for the process based on the business characteristics of the process itself, so as to meet the diversified needs of processes under various business characteristics.

[0111] For example, assuming that the first process is a process that frequently calls the first system service, the first target code configured for the first process can be a code that provides as few irrelevant functions as possible in the multiple codes, so as to reduce the time overhead as much as possible when the first process calls the first system service, and avoid affecting the performance of the first process. Assuming that the second process is a process that calls the first system service at a low frequency and is not sensitive to performance, the second target code configured for the second process can be a code that provides as many irrelevant functions as possible in the multiple codes, so as to reduce the modification to the prior art and ensure the normal operation of the operating system.

[0112] Optionally, in order to enable the kernel to determine which code to select for the process to provide the system service when obtaining the system call request from the process, a corresponding private system call table is set for the process in this application, so as to record the code corresponding to the process under each type of system call through the private system call table.

[0113] Exemplarily, the first system call request acquired by the kernel includes a system call number corresponding to the first system service and a process number corresponding to the first process.

[0114] Based on the system call number and the process number in the first system call request, a code address corresponding to the system call number is queried in a private system call table corresponding to the process number, to obtain an address of a first target code. The private system call table corresponds to the first process and is used to record the code addresses corresponding to various system call numbers, that is, the correspondence between various types of system calls and code addresses for the first process (equivalent to the correspondence between the first process and the first target code described above). Therefore, based on the private system call table, it can be determined which code should be executed to provide a system service when the first process executes various system calls.

[0115] After obtaining the address of the first target code, the address of the first target code is jumped to, to execute the first target code. By executing the first target code, the system function can be provided for the first process, thereby completing the process of the system call.

[0116] The above describes that the process number of the first process is used to determine the private system call table corresponding to the first process. In actual application, the kernel can establish a corresponding private system call table for each process. Moreover, the private system call table corresponding to each process is used to record the correspondence between the system call number and the code address. By querying the private system call table, the code address corresponding to the system call number carried in the system call request sent by the process can be determined, so as to determine which code is used to provide the system function corresponding to the system call.

[0117] In the present scheme, by setting the private system call table recording the correspondence between the system call number and the code address for the process, it can be determined based on the process number and the system call number which code is used to provide the system function corresponding to the system call for the current process, which is beneficial to quickly determine the code corresponding to the process in multiple codes providing the same system function, and further to select the most suitable system call code version for the process.

[0118] Specifically, the private system call table corresponding to the first process can be established when the first process starts running. That is, the kernel can establish a corresponding private system call table for each process starting to run. After establishing the corresponding private system call table for the first process, the kernel can also configure the corresponding addresses of various system call numbers in the private system call table.

[0119] Exemplarily, during the period when the first process does not invoke the first system service, the kernel configures the code address corresponding to the system call number of the first system service in the private system call table corresponding to the first process as the address of the first target code. In order to avoid errors during the execution of the system call, the kernel needs to ensure that the code address corresponding to the system call number of the first system service is configured during the period when the first process does not invoke the first system service.

[0120] It should be noted that, before the kernel configures the code address corresponding to the system call number as the address of the first target code, the system call number can be configured with no other code address or can be configured with other code address (i.e., the kernel actually modifies the code address corresponding to the system call number in the private system call table) in the private system call table corresponding to the first process, which is not limited in the present application.

[0121] In the present solution, by setting the kernel to configure the code address corresponding to each system call number in the private system call table corresponding to the process, the code version of the system call can be set or modified for the process in various scenarios, thereby improving the flexibility and realizability of the solution.

[0122] Optionally, before configuring the code address corresponding to the system call number as the address of the first target code, the running of the first process is suspended. And after the configuration of the code address corresponding to the system call number is completed, the running of the first process is resumed. In this way, by suspending the running of the first process during the configuration of the code address corresponding to the system call number, it can be ensured that the first process will not trigger the system call during this period, thereby avoiding the problem of system call error due to unsuccessful configuration of the code address corresponding to the system call number.

[0123] The above introduces the detailed process of configuring the code address in the private system call table corresponding to the first process. In the present application, there can be various ways to trigger the kernel to configure the code address in the private system call table corresponding to the first process.

[0124] In one possible implementation, the kernel determines the code version of the system call based on the collected behavior information of the first process executing the system call, and configures the corresponding code address in the private system call table.

[0125] Exemplarily, the kernel obtains the calling information of the first process for the first system service, the calling information comprising at least one of the frequency of the first process calling the first system service, the execution time of the first system service when called by the first process, the number of times of blocking of the first process when calling the first system service, and the number of times of preemption of the first process when calling the first system service. Wherein, the first process is blocked when calling the first system service generally refers to that the first process calling the first system service cannot normally run due to external reasons and needs to be put into waiting. For example, the first process calls the first system service to read a file, and the file is being modified by another process, so that the first process calling the first system service is blocked. The first process is preempted when calling the first system service refers to that the first process calling the first system service is preempted by other processes during the period. That is, since the processor is frequently switched among multiple processes, when the processor stops running the first process and switches to running other processes during the period of the first process calling the first system service, it means that the first process is preempted.

[0126] Based on the obtained calling information, the kernel can determine to use the first target code to provide the first system service for the first process in multiple codes to establish the corresponding relationship between the first process and the first target code.

[0127] In the scheme, by collecting the system call behavior of the process, the specific execution of the process for a type of system call can be obtained, so as to select the most matched system call code for the process in multiple codes, so as to improve the efficiency of the process executing the system call while ensuring the normal operation of the operating system as much as possible.

[0128] Exemplarily, in the case that the frequency of the first process calling the first system service is greater than the first threshold value and the execution time of the first system service is less than the second threshold value, the first target code is a code without providing irrelevant functions in multiple codes. That is, in the case that the first process frequently calls the first system service and the execution time of the first system service itself is short, the code without providing task-irrelevant functions can be selected for the first process, so as to reduce the time overhead of the first process calling the first system service as much as possible, and ensure that the performance of the first process is not greatly affected.

[0129] Or, in the case that the number of times of preemption of the first process when calling the first system service is greater than the third threshold value, the irrelevant functions provided by the first target code only include security enhancement functions. That is, the scheduling function in the irrelevant function set is removed to ensure that the first process will not be preempted when calling the first system service, so as to reduce the number of times of preemption of the first process when calling the first system service, and ensure the execution continuity of the first process.

[0130] Alternatively, in a case where the number of blocking times when the first process calls the first system service is greater than the fourth threshold value, the irrelevant functions provided by the first target code only include the scheduling function and the measurement function, so as to reduce the time overhead of each system call as much as possible on the premise of guaranteeing the basic functions.

[0131] The first threshold value, the second threshold value, the third threshold value and the fourth threshold value can be set or modified according to actual scenarios, and the application does not make specific limitations here.

[0132] It should be noted that the above introduces some examples of how to select a system call code version based on call information. In actual application, in addition to the above examples, the system call code version can also be selected based on call information according to other manners, and the application does not make specific limitations on the manner of how to select a system call code version based on call information.

[0133] In addition, as the first process continues to run, the call information of the first process for the first system service will continue to change. For example, the first process has a high frequency of calling the first system service in a previous time period, but has a low frequency of calling the first system service in a next time period. Therefore, in order to adapt to the real-time running state of the first process, the kernel can periodically select the code corresponding to the first system service for the first process based on the latest call information obtained, so as to ensure that the system call code version configured for the first process is always matched with the current running state of the first process.

[0134] In another possible implementation, the kernel configures the corresponding code address in the private system call table based on the obtained configuration instruction.

[0135] For example, during the running of the kernel, the kernel can obtain a configuration instruction, which is used to indicate that the code address corresponding to the system call number in the private system call table corresponding to the first process is configured as the address of the first target code. The configuration instruction can be issued by the management user to the kernel according to the running situation of the first process, to instruct the kernel to configure the corresponding code address for the first process. Moreover, the configuration instruction can be issued when the private system call table corresponding to the first process has not recorded the code address corresponding to the system call number, that is, the configuration instruction is used to configure the code address corresponding to the system call number for the first time. The configuration instruction can also be issued when the private system call table corresponding to the first process has recorded the code address corresponding to the system call number, that is, the configuration instruction is used to modify the code address corresponding to the system call number.

[0136] Then, based on the configuration instruction, the kernel triggers the configuration of the code address corresponding to the system call number as the address of the first target code in the private system call table.

[0137] In this solution, by selecting the corresponding system call code for the process in multiple codes based on the obtained configuration instruction, the system call code version corresponding to the process can be configured or adjusted based on the user's requirements, thereby meeting the diversified requirements of the user for the process running.

[0138] The above introduces that during the execution of the system call of the process, the system call code version matching the process is selected for the process in multiple codes, thereby minimizing the time overhead of the system call. Through the research of the applicant, it is found that in the prior art, when the system call is executed, the kernel often consumes a long time to save and restore the hardware context, thereby causing the overall time of executing the system call to become longer. Therefore, in this application, based on the type of the system service called by the process, the size of the hardware context to be saved is adaptively determined, thereby minimizing the actually saved hardware context and improving the efficiency of executing the system call.

[0139] Specifically, when the process calls the system service, the processor switches from the user state to the kernel state, and the hardware context corresponding to the process needs to be saved to record the running state of the process. In this way, after the processor switches to the kernel state and completes the calling of the system service, the processor switches from the kernel state to the user state, and the hardware context corresponding to the process is restored to continue running the process. The hardware context is essentially the value in the register. When the processor switches to the kernel state and executes the system service, for some simple system services, the value in part of the register may not change, that is, part of the hardware context corresponding to the process will not be changed. Therefore, in some cases, for some system services, all hardware contexts do not need to be saved.

[0140] Exemplarily, before executing the first target code, based on the type of the first system service provided by the first target code, the kernel determines the size of the hardware context to be saved, which is the value of the register. The hardware context to be saved can be the hardware context that may change during the execution of the first system service. Then, the kernel executes the saving of the hardware context based on the determined size of the hardware context, thereby realizing the saving of only the determined hardware context to be saved. The saved hardware context is used for recovery after the execution of the first target code is completed.

[0141] That is, after the process triggers the calling of the system service, the size of the hardware context to be saved is determined based on the type of the system service called by the process, thereby ensuring that the saved hardware context is the hardware context that will change during the execution of the system service, and avoiding saving all hardware contexts corresponding to the process.

[0142] In the scheme, the size of the hardware context actually saved is determined by the system service type triggered based on the process, which can reduce the saved hardware context as much as possible in actual application, and ensure that the efficiency of process execution system call is improved without affecting the normal operation of the process.

[0143] The execution process of the implementation method of the system call provided in the application is introduced above. For the convenience of understanding, the execution process of the implementation method of the system call in the actual application scenario will be introduced in detail below with specific examples.

[0144] In actual application scenarios, the system calls (hereinafter referred to as hot system calls) frequently executed in business scenarios such as smart phones, cloud computing, and smart cars are often different. For example, in the smart car business scenario, there are a large number of futex, nanosleep, and ioctl type system calls, and in the cloud computing business scenario and the high performance computing (HPC) business scenario, there are a large number of socket type system calls. Moreover, different business scenarios have different performance demands for the same system call. For example, the serverless business scenario is more sensitive to network connection performance, and the cache business scenario is not sensitive to network connection performance, where network connection involves listen, accept, connect, and other system calls. However, in the current operating system, the code implementation of the same system call is fixed regardless of the business scenario, which makes the implementation of the system call difficult to adapt to most businesses.

[0145] Therefore, based on the implementation method of the system call provided in the application, multiple code versions can be configured for the same system call, and the irrelevant function provision conditions of the multiple code versions are different. In this way, the most suitable code version can be selected for the process in multiple code versions based on the characteristics of the process executing the system call to implement the system call.

[0146] Exemplarily, please refer to Figure 4 , Figure 4 a schematic diagram of a system architecture provided in the application. As Figure 4 shown, the system architecture includes an application layer, a general library layer, and a kernel layer. The application layer includes various application programs running on the operating system, such as the database program MySQL, the cache program Redis, the high performance computing program, and the cloud native Severless business. The general library layer is the basic library on the operating system, for example, glibc.so on Linux. The application layer calls the system call function of the kernel through the general library layer.

[0147] The kernel layer includes four modules, namely, a system call configurator, a system call distributor, a privilege state switcher, and a system call filter.

[0148] It should be noted that the implementation method of the system call provided in the present application is mainly completed by the four modules of the kernel layer, and the entire process is not perceived by the application layer and the general library layer, so the application layer and the general library layer do not need to be changed.

[0149] Please refer to Figure 5 , Figure 5 Another schematic diagram of a system architecture provided in the present application is shown. As shown in Figure 5 The implementation method of the system call provided in the present application can be applied to an execution device such as a computer or a smart phone that is deployed with an operating system, and specifically can be implemented by program code of the operating system deployed on the execution device. For example, in the application scenario shown in Figure 5 The program code for implementing the method of the present application exists in the process management module, the exception handling module, and the file system of the operating system. At runtime, the program code for implementing the method of the present application runs in the operating system in the kernel state of the execution device.

[0150] Specifically, the exception handling module of the kernel is newly designed with a system call distributor, a system call filter, and a privilege level switcher. In the process management module, a process private table allocator is newly designed. In the file system, a system call configurator is newly designed. In the host memory, a private system call table (PST) of a process newly designed in the present application is stored.

[0151] The privilege level switcher is used to implement a lightweight privilege level switching function, to reduce the overhead of privilege level switching (i.e., switching from the user state to the kernel state and switching from the kernel state to the user state) in each system call process.

[0152] The system call distributor is used to query the PST of the process to implement the distribution of the system call, and the distributed system call can execute a customized code version to execute a customized function or skip irrelevant kernel functions.

[0153] The system call configurator is used to modify the content in the PST of the process, and write the system call that needs to be distributed into the PST.

[0154] The system call filter is used to filter out the system call that needs to be distributed according to the feature data during the running of the process, so that the system call configurator can modify the content in the PST of the process.

[0155] The process private table allocator is used to allocate the PST of the process when the process starts running, and recycle the PST when the process ends running.

[0156] The detailed working process of each module of the new design will be introduced below in combination with the drawings.

[0157] Please refer to Figure 6 , Figure 6 The working process of a privilege level switcher provided in the present application is shown in the figure. It can be understood that after a system call is triggered by an application (i.e. a process) running in the user mode, the privilege level switcher needs to be switched from the user mode to the kernel mode first, and then switched from the kernel mode to the user mode after the system call is completed. The privilege level switcher in the present application is used to realize the switching between the user mode and the kernel mode, and the scale of the hardware context to be saved is selected according to the complexity of the system function called in the system call process, so as to reduce the actual saved hardware context as much as possible and reduce the switching overhead of the privilege level.

[0158] As shown in Figure 6 , the working process of the privilege level switcher can include the following stages.

[0159] In stage one, when the process in the user mode initiates a system call request, the privilege level switcher in the kernel mode saves the minimum scale of the hardware context. The minimum scale of the hardware context refers to the hardware context that may be changed when executing any type of system call. Taking the Arm64 computer architecture as an example, the minimum scale of the hardware context may include, for example, the values in the following registers: registers x0-9, registers x20-x21, registers x28-x30, register elr_el1, and register spsr_el1.

[0160] In stage two, template matching is performed, which can be specifically selecting an overhead-minimal template code according to the type of the system call initiated by the process. Each template code is divided into a prologue template code and an epilogue template code, the prologue template code is responsible for switching from the user mode to the kernel mode, and the epilogue template code is responsible for switching from the kernel mode to the user mode. The scale of the hardware context saved by different template codes is different, so the execution overhead of different template codes is also different. If the function of the system call is simple, the scale of the hardware context that will be modified during the execution of the system call is small, and the privilege level switcher can match a template code with a small overhead, so that the scale of the saved hardware context is small; if the function of the system call is complex, the scale of the hardware context that will be modified during the execution of the system call is large, and the privilege level switcher can match a template code with a large overhead, so that the scale of the saved hardware context is large.

[0161] That is, stage one and stage two actually save a minimum size of hardware context first, and then further perform on-demand saving of hardware context based on the type of system call, so as to ensure that the size of the saved hardware context is as small as possible.

[0162] Stage three, execute the prologue template code, save the hardware context, and completely switch from user mode to kernel mode.

[0163] Stage four, execute the epilogue template code, restore the saved hardware context, and completely switch from kernel mode to user mode.

[0164] Please refer to Figure 7 , Figure 7 A system call shunt provided for the present application. As shown in Figure 7 , the system call shunt queries the PST corresponding to each process to query which code version should be used to execute the system call request initiated by each process.

[0165] Specifically, each process has a corresponding PST in memory, for example Figure 7 Process A corresponds to PST(A), process B corresponds to PST(B), and process C corresponds to PST(C). In this embodiment, the PST is essentially a system call whitelist, which records the system call numbers that need to execute customized code versions, and the addresses of the customized code versions corresponding to the system call numbers. Therefore, if the system call shunt can query a valid code address in the PST, it means that the system call currently initiated by the process can be implemented using the customized code version; if the system call shunt cannot query a code address (i.e. invalid address) in the PST, it means that the system call currently initiated by the process needs to be implemented using the native code version.

[0166] As shown in Figure 7 , the working process of the system call shunt includes the following stages.

[0167] Stage 1, parse the system call number and process number from the system call request sent by the process.

[0168] Stage 2, find the PST corresponding to the process according to the process number, and query the PST corresponding to the process according to the system call number.

[0169] Stage 3, if an effective code address is obtained by querying the PST, execute the code address obtained by querying to provide customized system call functions.

[0170] Stage 4, if the query of the PST does not get a valid code address, the native version of the code provided by the kernel is executed to provide the original system call function.

[0171] For example, in Figure 7 , the PST(A) records the code address of the customized version 1 of the read function (i.e. Readl address) and the code address of the customized version 1 of the lseek function (i.e. Lseekl address). Therefore, if the system call initiated by the process A is to call the read function or the lseek function, the customized version 1 code of the read function or the customized version 1 code of the lseek function can be executed according to the code address provided in the PST(A). If the system call initiated by the process A is to call the write function or the close function, since there is no valid code address in the PST(A) to query, the native version of the write function or the close function is executed.

[0172] Please refer to Figure 8 , Figure 8 , a system call configurator provided by the present application. During the running of the process, the code address in the PST corresponding to the process can be modified by the system call configurator, so that the code executed when the process triggers the system call can be switched between the native version code and the customized version code. Moreover, for the processes that need to run for a long time and the processes that are difficult to upgrade in a closed scenario, the implementation version of the switched system call should avoid restarting the process. Therefore, the system call configurator is set in the present application, which can switch between the native version code and the customized version code corresponding to the specified system call without exiting the running of the process.

[0173] Specifically, the working process of the system call configurator can include the following steps.

[0174] Step 1, the system call configurator obtains the system call number and the process number through the file system. For example Figure 8 , the nanosleep call number and the process number of the process A are shown.

[0175] Step 2, the system call configurator ensures that the process does not stay in the replaced system call function, and suspends the running of all threads under the process.

[0176] Step 3, the system call configurator obtains the PST to be modified through the process number, and then determines the PST entry to be modified in the PST through the system call number. For example, in the PST corresponding to process A, three entries are included, which are the code address of futex1, the code address of ioctl1, and the code address of nanosleep1; according to the nanosleep call number, the PST entry to be modified is the entry in which the code address of nanosleep1 is located.

[0177] Step 4, the system call configurator changes the PST entry to be modified to the address of the native version code or the address of the customized version code.

[0178] In the examples provided in the present application, the system call configurator can provide three different customized versions for each system call, which are: customized version one, customized version two and customized version three.

[0179] Compared with the native system call version, the customized version one skips all irrelevant functions, and the theoretical overhead is the lowest.

[0180] Compared with the native system call function, the customized version two only retains the security enhancement function, and balances between safety and performance.

[0181] Compared with the native system call function, the customized version three only retains the scheduling function and the measurement function, and is more suitable for file reading and writing, network transmission and other blocking system calls.

[0182] It should be noted that the above customized version one, customized version two and customized version three are only one possible example given by the present application, and in actual application, the customized version can be set according to actual needs, which is not limited here.

[0183] The above introduces the process of modifying the PST through the system call configurator, and the following reduces the process of triggering the system call configurator to modify the PST through the system call filter.

[0184] It should be noted that during the running of the process, many system calls will be generated, some system calls have a high number of triggers, some system calls have a long execution time, and some system calls can cause the process to sleep, that is, different types of system calls often have different characteristics. Therefore, the system call filter in the present application can analyze the system calls generated during the running of the process, and comprehensively analyze the process-related system call behavior information to filter out the hotspot system calls that have the greatest impact on the performance of the process, and then configure or modify the implementation code of the hotspot system calls.

[0185] Please refer to Figure 9 , Figure 9A workflow schematic diagram of a system call filter provided in the present application. As shown in Figure 9 , the workflow of the system call filter includes the following steps.

[0186] Step one, after being shunted by the system call shunt, a part of system call requests are processed according to the kernel's original system call function, that is, the system call is implemented by using the original code version.

[0187] Step two, the system call filter can obtain the call information of each system call of the process, such as the execution frequency of the system call, the execution time of the system call, the number of blocking times during the execution of the system call, and the number of preemption times during the execution of the system call.

[0188] Step three, the system call filter selects the customized version of the system call according to the following strategies:

[0189] a) For system calls with short execution time and high call frequency, the customized version one (i.e., the version skipping all irrelevant functions) is selected.

[0190] b) For system calls with many preemption times, the customized version two (i.e., only the security enhancement function is retained) is selected, thereby reducing the number of preemption times and ensuring the continuity of the process execution.

[0191] c) For system calls with many blocking times, the customized version three (i.e., only the scheduling function and the monitoring function are retained) is selected, thereby reducing the overhead of each system call as much as possible while ensuring the basic functions.

[0192] Step four, the system call filter triggers the system call configurator to configure the code address of the customized version of the system call into the PST of the process. Step four can be periodically run, for example, the PST of the process is configured once every second.

[0193] For the convenience of understanding, the following will introduce the redesign of the kernel FUEX_WAIT and FUTEX_WAKE system call functions in the open source MySQL database service.

[0194] Please refer to Figure 10 , Figure 10 An implementation flowchart of the original Futex system call provided in the present application. As shown in Figure 10As shown, the network worker thread of the MySQL database is responsible for reading the message from the network card and parsing the database query request. The database query thread reads and writes the database on the disk according to the specific content of the database query request. The network worker thread and the database query thread need to be coordinated through FUTEX_WAIT and FUTEX_WAKE in the futex system service provided by the kernel. Among them, the futex system service is a synchronization queuing service designed by the linux kernel for user space to realize lock synchronization mechanism. Two executors using futex need to be associated through a shared memory space. FUTEX_WAIT is used to queue and execute blocking (i.e. sleep scheduling), and FUTEX_WAKE is used to wake up the tasks (i.e. blocked threads) in the blocking queue.

[0195] The threads that need to work together on Linux compete for a futex resource belonging to the kernel. The threads that successfully compete will run first, and the threads that fail to compete will be suspended by the Linux kernel until the resource is released. Among them, the process of waking up the database query thread by the network worker thread includes two task switching operations, one low power mode operation and one interrupt processing operation. This set of operation processes will waste the processor's processing time of several hundred instruction cycles.

[0196] Please refer to Figure 11 , Figure 11 A system architecture for improving the performance of a database service is provided for the present application. As shown in Figure 11 , based on the system architecture provided by the present application, the notification and wake-up process between the network worker thread and the database query thread in the MySQL database service can be effectively improved. Among them, the software modules involved in the present application include the network worker thread (121) and the database query thread (122) of the MySQL database service (120); the exception handling module (104) of the operating system, the file system (105), the original Futex system call module (110), the kernel Idle thread (106), the scheduling module (107) and the interrupt processing module (108). The hardware involved in the present application includes the host memory (116), the network card (117) and the disk (115).

[0197] And, Figure 11The portion shown in the dashed box represents the new modules added to the existing operating system kernel in this application. Within the file system (105), this application designs a system call configurator (119); within the exception handling module (104), this application designs a privilege level switcher (123) and a system call distributor (124). Furthermore, this application adds a customized Futex system call module (109) to the operating system, and a private system call table (118) to the main memory data used by the kernel.

[0198] based on Figure 11 The system architecture shown implements a customized set of FUTEX_WAIT and FUTEX_WAKE functions. Specifically, FUTEX_WAIT allows the CPU to directly enter low-power mode. FUTEX_WAKE directly sends a wake-up event to cause the CPU to exit low-power mode and return to user mode to execute worker threads. In the optimized solution, the most time-consuming task switching operation is saved, thereby reducing the wake-up latency to a few dozen instruction cycles. This is because, although the database query thread needs to wait for the network worker thread to wake it up before it can continue working, if the CPU itself only executes the database query thread or a few other threads, frequent task switching actually incurs excessive unnecessary time overhead. Therefore, this application uses customized FUTEX_WAIT and FUTEX_WAKE functions to save the task switching steps and reduce time overhead.

[0199] Specifically, please refer to Figure 12 , Figure 12 This application provides a schematic diagram of an optimized process for database query threads. For example... Figure 12 As shown, the MySQL database query thread can effectively improve sleep latency through the FUTEX_WAIT function newly added in this application. The optimization process for the database query thread includes the following steps.

[0200] Step a: After the MySQL service starts the database query thread, the kernel generates a file named "xcall" in the proc filesystem for the database query thread. Figure 12 (1) in the middle.

[0201] Step b, the kernel configures the FUTEX_WAKE system call number through the xcall file under the proc filesystem, corresponding to Figure 13 (2) in the middle.

[0202] Step c, when the database query thread executes to FUTEX_WAIT, it jumps to the custom FUTEX_WAIT function entry point through the system call splitter (124) in this application, corresponding to... Figure 12(3) in the above.

[0203] Step d, the customized FUTEX_WAIT function also competes for the futex resource, if the competition fails and it is confirmed that no other task needs to occupy the CPU for execution, it enters the low-power mode through the Wait For Event (WFE) instruction. Among them, the WFE instruction is a processor instruction, which is used to make the processor enter the low-power mode, and the processor will not be awakened until a certain specific event occurs. If the customized FUTEX_WAIT function competes for the futex resource successfully, it means that the FUTEX_WAKE function has released the futex resource, and then the kernel's original FUTEX_WAIT function is directly executed, corresponding to(4) in the above. Figure 12

[0204] Please refer to Figure 13 , Figure 13 An optimization process for network worker threads is provided for the present application. As shown in Figure 13 , the optimization process for network worker threads includes the following steps.

[0205] Step a), after the MySQL service starts the network worker thread, the kernel generates a file named "xcall" under the proc file system for the network worker thread, corresponding to(1) in the above. Figure 13

[0206] Step b), the kernel configures the system call number of FUTEX_WAIT through the xcall file under the proc file system, corresponding to(2) in the above. Figure 13

[0207] Step c), when the network worker thread executes to FUTEX_WAKE, the kernel jumps to the customized FUTEX_WAKE function entry through the system call shunt (124), corresponding to(3) in the above. Figure 13

[0208] Step d), the customized FUTEX_WAKE function first confirms that the database query thread has put the CPU into the low-power mode, and then sends the wake-up event through the SVE instruction, corresponding to(4) in the above. Figure 13

[0209] Step e), the CPU where the database query thread is located receives the wake-up event, exits from the WFE instruction and competes for the futex resource again. If it competes for the futex resource successfully, it directly returns to the user state to query the database, otherwise it executes the FUTEX_WAIT function again, corresponding to(5) in the above. Figure 12

[0210] The method provided in this application has been described in detail above. Next, the device provided in this application for performing the above method will be described.

[0211] Please see Figure 14 , Figure 14 This is a schematic diagram of the structure of a system call implementation device provided in this application. Figure 14 As shown, the system call implementation device includes: an acquisition module 1401, used to acquire a first system call request from a first process, the first system call request being used to request a call to a first system service; and a processing module 1402, used to select a first target code from multiple codes for execution based on the correspondence between the first process and the first target code, so as to provide the first system service to the first process; wherein, multiple codes are all used to implement the first system service, and the multiple codes provide different irrelevant functions when they are executed, the irrelevant functions being functions that the first system service does not need to depend on when it is implemented.

[0212] In one possible implementation, the acquisition module 1401 is further configured to acquire call information of the first process for the first system service. The call information includes at least one of the frequency of the first process calling the first system service, the execution time of the first system service, the number of times the first process is blocked when calling the first system service, and the number of times it is preempted. The processing module 1402 is further configured to determine, based on the call information, to use the first target code to provide the first system service to the first process from among multiple codes, so as to establish a correspondence between the first process and the first target code.

[0213] In one possible implementation, the first system call request includes the system call number corresponding to the first system service and the process number corresponding to the first process; the processing module 1402 is specifically used to: query the code address corresponding to the system call number in the private system call table corresponding to the process number to obtain the address of the first target code; and jump to the address of the first target code to execute the first target code.

[0214] In one possible implementation, the processing module 1402 is further configured to: during the period when the first process does not call the first system service, configure the code address corresponding to the system call number in the private system call table as the address of the first target code.

[0215] In one possible implementation, the acquisition module 1401 is further configured to acquire a configuration instruction, which is used to instruct the code address corresponding to the system call number in the private system call table to be the address of the first target code; the processing module 1402 is further configured to, based on the configuration instruction, trigger the configuration of the code address corresponding to the system call number in the private system call table to be the address of the first target code.

[0216] In a possible implementation, the processing module 1402 is further configured to: suspend running of the first process before the code address corresponding to the system call number is configured as the address of the first target code; and resume running of the first process after the configuration of the code address corresponding to the system call number is completed.

[0217] In a possible implementation, before the first target code is executed, the processing module 1402 is further configured to: determine a size of hardware context that needs to be saved based on a type of the first system service provided by the first target code, the hardware context being a value of a register; and perform saving of the hardware context based on the size of the hardware context; wherein the saved hardware context is used to restore after the first target code is executed.

[0218] In a possible implementation, the obtaining module 1401 is further configured to obtain a second system call request from a second process, the second system call request being used to request to invoke the first system service; and the processing module 1402 is further configured to select a second target code from the plurality of codes to execute, based on a correspondence between the second process and the second target code, to provide the first system service to the second process.

[0219] In a possible implementation, in a case where a frequency of the first process invoking the first system service is greater than a first threshold value and an execution time of the first system service is less than a second threshold value, the first target code is a code that does not provide irrelevant functions from the plurality of codes; or in a case where a number of preemptions when the first process invokes the first system service is greater than a third threshold value, the irrelevant functions provided by the first target code only include security enhancement functions; or in a case where a number of blockings when the first process invokes the first system service is greater than a fourth threshold value, the irrelevant functions provided by the first target code only include scheduling functions and measurement functions.

[0220] In a possible implementation, the plurality of codes includes a first code, a second code and a third code, the first code is used to provide all irrelevant functions included in a set of irrelevant functions when the first code is executed, the second code is used to provide part of the irrelevant functions in the set of irrelevant functions when the second code is executed, and the third code is not used to provide the irrelevant functions in the set of irrelevant functions when the third code is executed.

[0221] Please refer to Figure 15 , Figure 15 A structural schematic diagram of an electronic device is provided for the present application. As shown in Figure 15 , the electronic device 1500 can specifically be a server, which is not limited herein. Specifically, the electronic device 1500 includes a receiver 1501, a transmitter 1502, a processor 1503 and a memory 1504 (wherein the number of the processor 1503 in the electronic device 1500 can be one or more, Figure 15The processor 1503 can include an application processor 15031 and a communication processor 15032, for example. In some embodiments of the present application, the receiver 1501, the transmitter 1502, the processor 1503 and the memory 1504 can be connected through a bus or other means.

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

[0223] The processor 1503 controls the operation of the electronic device. In a specific application, various components of the electronic 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. However, for the sake of clarity, various buses are referred to as a bus system in the figure.

[0224] The method disclosed in the above embodiments of the present application can be applied in the processor 1503 or implemented by the processor 1503. The processor 1503 can be an integrated circuit chip with a signal processing capability. In the implementation process, each step of the above method can be completed by an integrated logic circuit or an instruction in the form of software in the processor 1503. The processor 1503 mentioned above can be a general processor, a digital signal processor (DSP), a microprocessor or a microcontroller, and can further include an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.

[0225] The processor 1503 can implement or execute the disclosed methods, steps and logic block diagrams in the embodiments of the present application. The general processor can be a microprocessor or the processor can also be any conventional processor. The steps of the methods disclosed in 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 modules can be located in a random memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, a register, or other mature storage media in the art. The storage media is located in the storage 1504, and the processor 1503 reads the information in the storage 1504 and combines the hardware to complete the steps of the above-mentioned methods.

[0226] The receiver 1501 can be used to receive input digital or character information, and generate signal input related to the relevant settings and function control of the electronic device. The transmitter 1502 can be used to output digital or character information through the first interface; the transmitter 1502 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 1502 can also include a display device such as a display screen.

[0227] The electronic device provided by the embodiments of the present application can be a chip, which includes 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 the storage unit to enable the chip in the execution device to execute the methods described in the above embodiments. Alternatively, the storage unit is a storage unit in the chip, such as a register, a cache, etc. 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.

[0228] Reference can be made to Figure 16 , Figure 16 A structural schematic diagram of a computer readable storage medium provided by the present application is provided. The present application also provides a computer readable storage medium, in some embodiments, the above Figure 3 The disclosed methods can be implemented as computer program instructions encoded in a computer readable storage medium in a machine readable format or encoded in other non-transitory media or articles.

[0229] Figure 16 A conceptual partial view of an example computer readable storage medium arranged in accordance with at least some embodiments shown herein is schematically illustrated, the example computer readable storage medium including a computer program for executing a computer process on a computing device.

[0230] In one embodiment, the computer-readable storage medium 1600 is provided using a signal bearing medium 1601. The signal bearing medium 1601 can include the one or more program instructions 1602 embodied in the medium 1603, which when executed by one or more processors, can provide the functionality or portions thereof described above. Figure 3

[0231] In some examples, the signal bearing medium 1601 can encompass a computer- readable medium 1603, such as, but not limited to, a hard disk drive, a compact disk (CD), a digital video disk (DVD), a memory, a ROM, a RAM, or the like.

[0232] In some embodiments, the signal bearing medium 1601 can encompass a computer- recordable medium 1604, such as, but not limited to, a memory, a read / write (R / W) CD, a R / W DVD, and the like. In some embodiments, the signal bearing medium 1601 can encompass a communications medium 1605, such as, but not limited to, a digital and / or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communication link, a wireless communication link, and the like). Thus, for example, the signal bearing medium 1601 can be delivered by a wireless form of the communication medium 1605 (e.g., wireless communication medium complying with the IEEE 802.X standards, or the like).

[0233] The one or more program instructions 1602 can be, for example, computer- executable instructions or logic-implemented instructions. In some examples, a computing device of a computing device can be configured to provide various operations, functions, or actions in response to the program instructions 1602 conveyed to the computing device by one or more of the computer-readable medium 1603, the computer-recordable medium 1604, and / or the communication medium 1605.

[0234] It should be noted that the apparatus embodiments described above are merely exemplary, and that the units shown as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purposes of the embodiments. In addition, the apparatus embodiments provided in the drawings of the present application indicate that there is a communication connection between the modules. Specifically, it can be implemented as one or more communication buses or signal lines.

[0235] ​Those skilled in the art can clearly understand that the application can be implemented by means of software plus necessary universal hardware, of course, also can be implemented by special hardware including special integrated circuit, special CPU, special memory, special component, etc. Generally, the functions completed by computer program can be easily implemented by corresponding hardware, and the specific hardware structure for implementing the same function can also be various, such as analog circuit, digital circuit or special circuit, etc. However, for the application, the software program implementation is the better embodiment. Based on such understanding, the technical solutions of the application can be embodied in the form of software product, which is stored in a readable storage medium, such as computer floppy disk, U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk, etc., including a plurality of instructions for making a computer device (which can be a personal computer, training device, or network device, etc.) execute the method of each embodiment of the application.

[0236] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments can be implemented in the form of a computer program product.

[0237] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, all or part of the processes or functions according to the embodiments of the application are 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 transferred from one computer readable storage medium to another, for example, the computer instructions can be transmitted from one website site, computer, training device or data center to another website site, computer, training device or data center through wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) mode. The computer readable storage medium can be any available medium that the computer can store or the data storage device such as training device, data center, etc. integrated with one or more available media. The available media can be magnetic media (such as floppy disk, hard disk, magnetic tape), optical media (such as DVD), or semiconductor media (such as solid state disk (SSD)), etc.

Claims

1. A method for implementing a system call, characterized in that, include: Obtain the first system call request from the first process, the first system call request being used to request a call to the first system service; Based on the correspondence between the first process and the first target code, the first target code is selected from multiple codes for execution to provide the first system service to the first process; The multiple codes are all used to implement the first system service, and the multiple codes provide different irrelevant functions when they are executed. The irrelevant functions are functions that the first system service does not need to depend on when it is implemented.

2. The method according to claim 1, characterized in that, The method further includes: Obtain the call information of the first process for the first system service. The call information includes at least one of the following: the frequency at which the first process calls the first system service, the execution time of the first system service, the number of times the first process is blocked when calling the first system service, and the number of times it is preempted. Based on the invocation information, the first target code is selected from among the plurality of codes to provide the first system service to the first process, so as to establish a correspondence between the first process and the first target code.

3. The method according to claim 1 or 2, characterized in that, The first system call request includes the system call number corresponding to the first system service and the process number corresponding to the first process; The step of selecting the first target code to execute from among multiple codes based on the correspondence between the first process and the first target code includes: The code address corresponding to the system call number is queried in the private system call table corresponding to the process number to obtain the address of the first target code; Jump to the address of the first target code to execute the first target code.

4. The method according to claim 3, characterized in that, The method further includes: During the period when the first process does not call the first system service, the code address corresponding to the system call number is configured as the address of the first target code in the private system call table.

5. The method according to claim 4, characterized in that, The method further includes: Obtain a configuration instruction, the configuration instruction being used to instruct the code address corresponding to the system call number in the private system call table to be the address of the first target code; Based on the configuration instruction, the code address corresponding to the system call number is configured in the private system call table as the address of the first target code.

6. The method according to claim 4 or 5, characterized in that, The method further includes: Before configuring the code address corresponding to the system call number as the address of the first target code, pause the execution of the first process; After configuring the code address corresponding to the system call number, the first process resumes execution.

7. The method according to any one of claims 1-6, characterized in that, Before executing the first target code, the method further includes: Based on the type of the first system service provided by the first target code, the size of the hardware context to be saved is determined, wherein the hardware context is the value of a register; Based on the size of the hardware context, perform the saving of the hardware context; The saved hardware context is used to restore the first target code after it has been executed.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: Obtain a second system call request from the second process, the second system call request being used to request an invocation of the first system service; Based on the correspondence between the second process and the second target code, the second target code is selected from the plurality of codes for execution to provide the first system service to the second process.

9. The method according to any one of claims 1-8, characterized in that, If the frequency of the first process calling the first system service is greater than the first threshold and the execution time of the first system service is less than the second threshold, the first target code is the code among the plurality of codes that does not provide irrelevant functions; Alternatively, if the number of times the first process is preempted when calling the first system service exceeds the third threshold, the irrelevant functions provided by the first target code shall only include security enhancement functions. Alternatively, if the number of times the first process calls the first system service is greater than the fourth threshold, the irrelevant functions provided by the first target code shall only include scheduling and maintenance functions.

10. The method according to any one of claims 1-9, characterized in that, The plurality of codes includes a first code, a second code, and a third code. When the first code is executed, it is used to provide all the irrelevant functions included in the irrelevant function set. When the second code is executed, it is used to provide some of the irrelevant functions in the irrelevant function set. When the third code is executed, it is not used to provide the irrelevant functions in the irrelevant function set.

11. A system call implementation apparatus, characterized in that, include: The acquisition module is used to acquire the first system call request from the first process, and the first system call request is used to request to call the first system service; The processing module is used to select the first target code from multiple codes for execution based on the correspondence between the first process and the first target code, so as to provide the first system service to the first process; The multiple codes are all used to implement the first system service, and the multiple codes provide different irrelevant functions when they are executed. The irrelevant functions are functions that the first system service does not need to depend on when it is implemented.

12. The apparatus according to claim 11, characterized in that, The acquisition module is further configured to acquire the call information of the first process for the first system service, the call information including at least one of the frequency of the first process calling the first system service, the execution time of the first system service, the number of times the first process is blocked when calling the first system service, and the number of times it is preempted; The processing module is further configured to determine, based on the calling information, from among the plurality of codes to use the first target code to provide the first system service to the first process, so as to establish a correspondence between the first process and the first target code.

13. The apparatus according to claim 11 or 12, characterized in that, The first system call request includes the system call number corresponding to the first system service and the process number corresponding to the first process; The processing module is specifically used for: The code address corresponding to the system call number is queried in the private system call table corresponding to the process number to obtain the address of the first target code; Jump to the address of the first target code to execute the first target code.

14. The apparatus according to claim 13, characterized in that, The processing module is further configured to: During the period when the first process does not call the first system service, the code address corresponding to the system call number is configured as the address of the first target code in the private system call table.

15. The apparatus according to claim 14, characterized in that, The acquisition module is further configured to acquire a configuration instruction, the configuration instruction being configured to instruct the code address corresponding to the system call number in the private system call table to be the address of the first target code; The processing module is further configured to, based on the configuration instruction, trigger the configuration of the code address corresponding to the system call number in the private system call table as the address of the first target code.

16. The apparatus according to claim 14 or 15, characterized in that, The processing module is further configured to: Before configuring the code address corresponding to the system call number as the address of the first target code, pause the execution of the first process; After configuring the code address corresponding to the system call number, the first process resumes execution.

17. The apparatus according to any one of claims 11-16, characterized in that, Before executing the first target code, the processing module is further configured to: Based on the type of the first system service provided by the first target code, the size of the hardware context to be saved is determined, wherein the hardware context is the value of a register; Based on the size of the hardware context, perform the saving of the hardware context; The saved hardware context is used to restore the first target code after it has been executed.

18. The apparatus according to any one of claims 11-17, characterized in that, The acquisition module is further configured to acquire a second system call request from the second process, the second system call request being used to request to call the first system service; The processing module is further configured to select the second target code from the plurality of codes for execution based on the correspondence between the second process and the second target code, so as to provide the first system service to the second process.

19. The apparatus according to any one of claims 11-18, characterized in that, If the frequency of the first process calling the first system service is greater than the first threshold and the execution time of the first system service is less than the second threshold, the first target code is the code among the plurality of codes that does not provide irrelevant functions; Alternatively, if the number of times the first process is preempted when calling the first system service exceeds the third threshold, the irrelevant functions provided by the first target code shall only include security enhancement functions. Alternatively, if the number of times the first process calls the first system service is greater than the fourth threshold, the irrelevant functions provided by the first target code shall only include scheduling and maintenance functions.

20. The apparatus according to any one of claims 11-19, characterized in that, The plurality of codes includes a first code, a second code, and a third code. When the first code is executed, it is used to provide all the irrelevant functions included in the irrelevant function set. When the second code is executed, it is used to provide some of the irrelevant functions in the irrelevant function set. When the third code is executed, it is not used to provide the irrelevant functions in the irrelevant function set.

21. A system call implementation apparatus, characterized in that, The device includes a memory and a processor; the memory stores code, and the processor is configured to execute the code, wherein when the code is executed, the device performs the method as described in any one of claims 1 to 10.

22. A computer storage medium, characterized in that, The computer storage medium stores instructions that, when executed by the computer, cause the computer to perform the method according to any one of claims 1 to 10.

23. A computer program product, characterized in that, The computer program product stores instructions that, when executed by a computer, cause the computer to perform the method described in any one of claims 1 to 10.

Images