|Projects Publications Resume Contact About Youtube Donate||
The advantages of user-space drivers [applications] are:
- The full C library can be linked in. The driver can perform many exotic tasks without resorting to external programs (the utility programs implementing usage policies that are usually distributed along with the driver itself).
- The programmer can run a conventional debugger on the driver code without having to go through contortions to debug a running kernel.
- If a user-space driver hangs, you can simply kill it. Problems with the driver are unlikely to hang the entire system, unless the hardware being controlled is really misbehaving.
- User memory is swappable, unlike kernel memory. An infrequently used device with a huge driver wonít occupy RAM that other programs could be using, except when it is actually in use.
- A well-designed driver program can still, like kernel-space drivers, allow concurrent access to a device.
- If you must write a closed-source driver, the user-space option makes it easier for you to avoid ambiguous licensing situations and problems with changing kernel interfaces. (Corbet, Kroah-Hartman, & Rubini, 2005, p. 38)
But the user-space approach to device driving has a number of drawbacks. The most important are:
- Interrupts are not available in user space. There are workarounds for this limitation on some platforms, such as the vm86 system call on the IA32 architecture.
- Direct access to memory is possible only by mmapping /dev/mem, and only a privileged user can do that.
- Access to I/O ports is available only after calling ioperm or iopl. Moreover, not all platforms support these system calls, and access to /dev/port can be too slow to be effective. Both the system calls and the device file are reserved to a privileged user.
- Response time is slower, because a context switch is required to transfer information or actions between the client and the hardware.
- Worse yet, if the driver has been swapped to disk, response time is unacceptably long. Using the mlock system call might help, but usually youíll need to lock many memory pages, because a user-space program depends on a lot of library code. mlock, too, is limited to privileged users.
- The most important devices canít be handled in user space, including, but not limited to, network interfaces and block devices. (Corbet et al., 2005, p. 39)
|Method||Write Speed MB/s||Read Speed MB/s|
|Raw / no encryption||57||43|
|Method||Netperf MB/s||ISCSI MB/s||Netcat MB/s||Filemover MB/s|
|Raw / no encryption||230||165||126||225|
|Dual 3.0GHzXeon MB/s||Dual dual-core 265 Opteron MB/s||Single 2.53GHz Celeron MB/s|
|RHEL5LSPP x86_64||RHEL5LSPP x86_64||RHEL5LSPP i686|
|Kernel speed % of user||-21||-12||-6|
|Method||Filemover Speed MB/s|
|Single server process no encryption||213|
|Single server process with encryption||38|
|Multithreaded server with encryption (1 CPU)||72|
|Forked server with encryption (2 CPUs)||61|
|Server||1 process speed MB/s||4 process speed MB/s|
|Dual 3.0GHz Xeon||80||160|
|Dual Dual-Core 265 Opteron||60||240|
We demonstrate that the gap in the performance of the two servers becomes less significant as the proportion of dynamic-content requests increases. In fact, for workloads with a majority of dynamic requests, the u-server outperforms TUX. We conclude that a well-designed user-space web server can compete with an in-kernel server on performance, while retaining the reliability and security benefits that come from operating in user space. (Brecht, Li, Shukla, Subramanian, & Ward, 2004, p. 1)
This project has two goals. The first goal is to improve application performance by reducing context switches and data copies. We do this by either running select sections of the application in kernel-mode, or by creating new, more efficient system calls. The second goal is to ensure that kernel safety is not violated when running user-level code in the kernel. (Callanan, Rai, Sivathanu, Traeger, & Zadok, 2005, p. 1)
The /proc filesystem is a special, software-created filesystem that is used by the kernel to export information to the world. Each file under /proc is tied to a kernel function that generates the fileís "contents" on the fly when the file is read... Fully featured /proc entries can be complicated beasts; among other things, they can be written to as well as read from. (Corbet et al., 2005, p. 83)The proc and other virtual filesystems provide a way to perform I/O and interact with running kernel modules.