Return to kernel.t CVS log

Up to [CSRG BSD Unix] / 43BSD / contrib / X / doc / Usenix

Annotation of 43BSD/contrib/X/doc/Usenix/kernel.t, revision 1.1.1.1

1.1       root        1: .SH
                      2: Alternatives to User Process Window Systems
                      3: .PP
                      4: As currently implemented on most machines, the 
                      5: .UX
                      6: kernel
                      7: does not
                      8: permit preemption once a user process has started executing a system call
                      9: unless the system call explicitly blocks.
                     10: Any asynchrony occurs at device driver interrupt level.
                     11: .UX
                     12: presumes either that system calls are very fast
                     13: or quickly block waiting for I/O completion.
                     14: .PP
                     15: This has strong implications for kernel window system implementations.
                     16: While window system requests do not take very long
                     17: (if they did, the presumptions made in X would be unacceptable),
                     18: they may take very long relative to normal system calls.
                     19: If a system call is compute bound for a ``long period'', interactive
                     20: response of other processes suffers badly, as the offending process
                     21: will tend to monopolize the CPU.
                     22: One might argue that this is not offensive on a single user machine
                     23: but it is a disaster on a multiuser machine.
                     24: If graphics code and data is in the kernel for sharing,
                     25: it permanently uses that much of
                     26: kernel memory, incurs system call overhead for access,
                     27: and cannot be paged out when not in use.
                     28: .PP
                     29: Similarly, in X as well as most other window systems,
                     30: if a window system request takes too long,
                     31: other clients will not get their fair share of the display.
                     32: This is currently somewhat of a problem during complex fill or
                     33: polyline primitives on slow displays.
                     34: The concept of interrupting a graphics primitive is so difficult that
                     35: we have chosen to ignore the problem, which is seldom noticeable.
                     36: If such graphics primitives occur in system calls, they have a much
                     37: greater impact on process scheduling.
                     38: .PP
                     39: An alternative to a strictly kernel window system implementation
                     40: splits responsibility between the kernel and user processes.
                     41: Synchronization, window creation and manipulation primitives are put in
                     42: the kernel, and clients are relied on to be well behaved for clipping.
                     43: Output to the window is then performed in each user process.
                     44: This has several disadvantages (presuming no shared libraries, not
                     45: available on most current 
                     46: .UX
                     47: implementations).
                     48: Each client of the window system must must then have
                     49: a full copy of graphics code.
                     50: This can be quite large on
                     51: some hardware, replicated in each client of the window system.
                     52: For example, the current bit blit, graphics and clipping code for QVSS
                     53: is approximately
                     54: 90kbytes, or 18000 lines of C source code.
                     55: Fill algorithms may also require a large amount of buffer space.
                     56: .PP
                     57: Even worse  (as the number of different display hardware proliferates
                     58: with time on a single machine architecture) is that this split
                     59: approach requires the inclusion in your image 
                     60: of code for
                     61: hardware you do not currently have.
                     62: Upward compatibility to new display hardware is also impossible without
                     63: shared libraries,
                     64: but dynamic linking is really required for
                     65: the general solution.
                     66: .PP
                     67: With much existing hardware it is hard
                     68: to synchronize requests from multiple processes
                     69: if the hardware has not been designed to efficiently support context switching.
                     70: There are sometimes work arounds for these problems by ``shadowing''
                     71: the write only state in the hardware.
                     72: We have seen displays which incur additional hardware cost 
                     73: to allow for
                     74: such multiprocess access.
                     75: One must also then face the locking of critical sections of window system
                     76: data structures if the window system is interruptible.
                     77: .PP
                     78: .UX
                     79: internal kernel structuring currently provides most services directly
                     80: to user processes.
                     81: It would be difficult to provide network access to the window system
                     82: if it were in the kernel due to this horizontal structure but a
                     83: better ability to layer one facility on another would improve this
                     84: situation.
                     85: Again, this is a failure of the kernel to be sufficiently modular to
                     86: anticipate the evolving environment.
                     87: .PP
                     88: X finesses all of these problems:
                     89: 1) X and client applications are user processes; ergo no scheduling biases.
                     90: 2) There is only one copy of display code required, in the server,
                     91: which can be paged since it is completely user code.
                     92: This also saves swap space, in short supply on most current workstations.
                     93: The resulting client code is thus small.
                     94: Minimal X applications are as small as 16k bytes.
                     95: No graphics code is in an application program.
                     96: 3) Client code can potentially work with new hardware without relinking, as
                     97: no display specific code appears in a client program image.
                     98: 4) Network access to the window system comes at no additional cost,
                     99: and no performance penalty (in practice, performance is often gained).
                    100: 5) X avoids system call overhead by buffering requests into a single
                    101: buffer and delaying writing in a fashion similar to the standard I/O library.
                    102: The system call overhead for output is therefore reduced by well over an
                    103: order of magnitude per X operation.
                    104: 6) User process code is easy to debug.
                    105: Some complications can arise due to the distributed nature of the system.
                    106: In practice, this has rarely been a problem.
                    107: 7) Applications requiring a ``compute server'' can be run from the
                    108: user's workstation.
                    109: .PP
                    110: Kernel lightweight processes could be used to solve
                    111: the non-preemptable nature
                    112: of system calls and would create more
                    113: options for window system implementations.
                    114: Since raster operations can be quite long lived,
                    115: performing these in the current structure allows one process to
                    116: monopolize the system to the detriment of other processes.
                    117: Since all context in the system call layer of the
                    118: kernel is associated with a user process, there is
                    119: currently no way to divorce such operations from a process and
                    120: schedule them independently.
                    121: .PP
                    122: While lightweight processes would unnecessarily complicate the X server
                    123: design (requiring us to lock data structures and perform synchronization),
                    124: they could be used prevent the most common X programming mistake.
                    125: Programmers new to X invariably forget to flush the output buffer when
                    126: testing their first program.
                    127: A timer driven lightweight process in clients  would be useful to guarantee
                    128: automatic flushing of the buffers.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.