Return to kernel.t CVS log

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

Annotation of 43BSDTahoe/new/X/doc/Usenix/kernel.t, revision 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.