Patent Application
20090199202
This invention relates generally to asynchronous system calls, more particularly to systems and method for an asynchronous system call interface and execution thereof.
The Linux kernel currently provides for a system call interface for asynchronous input/output (“AIO”). AIO can provide a path to better system resource utilization by letting a single process do independent work in parallel.
As a simplistic example, the calculation of a cryptographic hash of a very large file typically involves reading the file into pieces into memory and each piece is then hashed. With synchronous read ( ) calls, the central processing unit (CPU) can be idle while each piece is read from the file. Subsequently, as the CPU hashes the pieces in memory, the disk is idle. Making an assumption that the it takes the same amount of time to read piece as it takes to calculate its hash, the system is only working at half capacity. However, if AIO is used, the process can be fully utilize the CPU and disk by letting the disk issue the read for the next piece without blocking the CPU.
Although AIO can provide great benefits, it is not without disadvantages and drawbacks. For example, the current implementation of AIO supports few operations and only provides asynchronous submission and completion of those operations in limited circumstances. The current AIO implementation has only succeeded in providing cache-avoiding reads and writes to regular files, used almost exclusively by database software. The maintenance burden for so little functionality has proved to be disproportionately difficult which has also discouraged adding support for other operations.
Various features of the embodiments can be more fully appreciated, as the same become better understood with reference to the following detailed description of the embodiments when considered in connection with the accompanying figures, in which:
For simplicity and illustrative purposes, the principles of the present invention are described by referring mainly to exemplary embodiments thereof. However, one of ordinary skill in the art would readily recognize that the same principles are equally applicable to, and can be implemented in, all types of operating systems that execute multiple applications, and that any such variations do not depart from the true spirit and scope of the present invention. Moreover, in the following detailed description, references are made to the accompanying figures, which illustrate specific embodiments. Electrical, mechanical, logical and structural changes may be made to the embodiments without departing from the spirit and scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense and the scope of the present invention is defined by the appended claims and their equivalents.
Embodiments relate generally to systems and methods for a generic system call interface for performing asynchronous operations. More particularly, the generic system call interface includes a syslet atom data structure that includes a number of fields: number of the system call, pointer to the arguments, a return pointer for the final status from the submitted call, a private field, a next field which points to the next syslet to be run by the kernel, and a flag field which controls how the syslets are executed.
With the syslet atom data structure filled in user space, an application (e.g., database, cryptographic program, etc.) can execute the asynchronous system call by executing an asynchronous system call such as “long async_exec (struct syslet_uatom*atom)”. The kernel can then begin executing immediately. If the executed call executes without being blocked, the address of the syslet atom data structure indicate complete execution through a return value. Otherwise, the kernel can be configured to grab a thread from a kernel thread pool and use the selected thread to return to user space, and the called asynchronous system call continues with the original thread. In some embodiments, the selected thread can be used for syslet execution. Accordingly, the application can then be free to continue executing as it makes sense such as running more syslet atom data structures while the system call runs to completion.
With the generic system call interface, an application can register a ring buffer with the kernel using yet another function call such as an “async_register( )”. When a syslet atom completes, the completed syslet atom's address can be stored in the next available empty buffer entry. Accordingly, the application can then use that address to find the associated system call status. The kernel can be configured not to overwrite any non-NULL ring buffer entries so the application must reset them as it releases them. If an application needs to wait for a completion of syslet atom data structure, the application can execute a wait function such as “long async_wait (unsigned long min_events)”) as long as this interface is relative to a “measurement” in some embodiments. This function call can block the process until at least a minimum number of events (“min_events”) have been stored into the ring buffer.
As shown in
The kernel 120 can include a syslet interface module 130. The syslet interface 130 can be configured to provide a user to access asynchronous system calls executed by the kernel 120 for applications, processes, jobs, tasks, threads, etc. The syslet interface 130 can couple with a syslet atom data structure that includes a number of fields: number of the system call, pointer to the arguments, a return pointer for the final status from the submitted call, a private field, a next field which points to the next syslet to be run by the kernel, and a flag field which controls how the syslets are executed.
With the syslet atom data structure filled in user space, application 115 (e.g., database, cryptographic program, etc.) can execute the asynchronous system call by executing an asynchronous system call such as “long async_exec (struct syslet_uatom*atom)”. The kernel 120 can then begin executing immediately. If the embedded systems calls execute without being blocked, a positive response from the syslet atom data structure will be returned. Otherwise, the kernel 120 can be configured to grab a thread from a thread pool and use the selected thread to return to user space, and the called asynchronous system call continues with the original thread or continue on with a new syslet. Accordingly, the application 115 can then be free to execute as it makes sense such as running more syslet atom data structures while the system call runs to completion.
With the syslet interface module 130, an application 115 can register a ring buffer with the kernel 120 using yet another function call such as an “async_register( )”. When a syslet atom data structure completes, the completed syslet atom's address can be stored in the next available empty buffer entry. Accordingly, the application 115 can then use that address to find the associated system call status. The kernel 120 can be configured not to overwrite any non-NULL ring buffer entries so the application must reset them as it releases them.
The article i was basing my description was not clear) If an application 115 needs to wait for a completion of syslet atom data structure, the application 115 can execute a wait function such as “long async_wait (unsigned long min_events)” in some embodiments. This function call can block the process until at least a minimum number of events (“min_events”) have been stored into the ring buffer.
As shown in
In some embodiments, a SYSLET_SYNC flag can be set in the flags field 205. Accordingly, some implementations using syslet atoms can execute these embedded system calls in parallel unless explicitly or implicitly prevented.
The system call number field 210 can indicate the number of the system call to run when set with a value. The return pointer field 215 can indicate to the kernel 120 where to put the final status from the executed asynchronous call when set with a value. The pointer to arguments field 220 can indicate a pointer to the arguments of the syslet atom when set with a value. The next syslet field 225 can indicate the user address of the next syslet to be executed when set with a value. Accordingly, an application 115 is not restricted to running individual asynchronous system calls and can chain a series of syslets.
As shown in
In step 310 the kernel 120 can be configured to execute the specified asynchronous call. If the kernel 120 is blocked, in step 315, the kernel 120 can be configured to retrieve another thread from a thread pool, in step 320. The kernel 120 can be configured to let the syslet atom execute on the original thread and return to user space on the second thread, in step 325. Subsequently, the kernel 120 can execute the next instruction of the program after returning to userspace.
Otherwise, the kernel 120 can return the result of the executed syslet, in step 330. The kernel 120 can write to the results to the location pointed by a value set in the return pointer field 215. Alternatively, the kernel 120 can write the results to a ring buffer instantiated by the application 115 by executing another function call such as “async_register( )”.
In step 335, the kernel 120 can be configured to examine the value set in the next syslet field 225. If the value is non-null, the kernel 120 can be configured to execute the next syslet specified by the value in the next syslet field 225, in step 345. Subsequently, the kernel 120 can return to the processing associated with step 310. Otherwise, if the value is null in the next syslet field 225, the kernel 120 can return to user space to execute the next process, task, instruction, etc., in step 340.
As shown in
Certain embodiments may be performed as a computer program. The computer program may exist in a variety of forms both active and inactive. For example, the computer program can exist as software program(s) comprised of program instructions in source code, object code, executable code or other formats; firmware program(s); or hardware description language (HDL) files. Any of the above can be embodied on a computer readable medium, which include storage devices and signals, in compressed or uncompressed form. Exemplary computer readable storage devices include conventional computer system RAM (random access memory), ROM (read-only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), and magnetic or optical disks or tapes. Exemplary computer readable signals, whether modulated using a carrier or not, are signals that a computer system hosting or running the present invention can be configured to access, including signals downloaded through the Internet or other networks. Concrete examples of the foregoing include distribution of executable software program(s) of the computer program on a CD-ROM or via Internet download. In a sense, the Internet itself, as an abstract entity, is a computer readable medium. The same is true of computer networks in general.
While the invention has been described with reference to the exemplary embodiments thereof, those skilled in the art will be able to make various modifications to the described embodiments without departing from the true spirit and scope. The terms and descriptions used herein are set forth by way of illustration only and are not meant as limitations. In particular, although the method has been described by examples, the steps of the method may be performed in a different order than illustrated or simultaneously. Those skilled in the art will recognize that these and other variations are possible within the spirit and scope as defined in the following claims and their equivalents.
