Return to memory.t CVS log

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

Annotation of 43BSD/contrib/X/doc/Usenix/memory.t, revision 1.1

1.1     ! root        1: .SH
        !             2: Shared Memory
        !             3: .PP
        !             4: On a fast display and processor, X may be performing more than
        !             5: one thousand operations (X requests) per second.
        !             6: If every access to the device requires a system call, the overhead
        !             7: rapidly predominates all other costs.
        !             8: X uses a shared memory structure with the device driver for two purposes:
        !             9: 1) to get mouse and keyboard input
        !            10: and
        !            11: 2) to access the device or write into a memory bitmap.
        !            12: .PP
        !            13: As pointed out before, X is a single threaded server.
        !            14: Since client programs should be able to overlap with
        !            15: the window system as much as possible (remember that you may be
        !            16: running applications on other machines), it is particularly
        !            17: important to send input events to the correct client as soon
        !            18: as possible.
        !            19: It is therefore desirable to test if there is input after each
        !            20: graphic output operation.
        !            21: This test can be performed in only a couple of instructions given shared
        !            22: memory, and would otherwise require either one system call/output
        !            23: operation (to check for new input) or a compromise in how quickly
        !            24: input would be handled.
        !            25: .PP
        !            26: All input events are put into a shared memory circular buffer; since
        !            27: the driver only inserts into the buffer, and X only removes from the
        !            28: buffer, synchronization is easy to provide with separate head and tail
        !            29: indices (presuming a write to shared memory is atomic).
        !            30: .PP
        !            31: Output on the QVSS is directly to a mapped bitmap.
        !            32: In the case of the Vs100, a piece of the UNIBUS\(dg and a shared DMA buffer
        !            33: are statically mapped where both the driver and the X server can access
        !            34: them.
        !            35: .FS \(dg
        !            36: UNIBUS is a trademark of Digital Equipment Corporation.
        !            37: .sp
        !            38: .FE
        !            39: Output requests to the Vs100 are directly formated into this buffer,
        !            40: minimizing copying of data.\(dd
        !            41: .FS \(dd
        !            42: Our thanks go to Phil Karlton, of Digital's Western Research Lab, for
        !            43: the first implementation of this mechanism.
        !            44: .FE
        !            45: This permits the device dependent routines to start I/O transfers without
        !            46: system call overhead (by directly accessing device CSR registers),
        !            47: and avoids UNIBUS map setup overhead that DMA from user space requires.
        !            48: .PP
        !            49: These changes dramatically increased performance and improved
        !            50: interactive feel when implemented, while greatly reducting CPU overhead.
        !            51: Since proper memory sharing primitives are lacking in 4.2BSD,
        !            52: it was implemented by making pages readable and writable in system space,
        !            53: where they are accessible to any process.
        !            54: In theory, any program on the machine could cause a Vs100 implementation to
        !            55: machine check (odd byte access in the UNIBUS space), though in practice it
        !            56: has never happened.
        !            57: None the less, it is the ugliest piece of the current X implementation.
        !            58: We are more willing to allow a server process to access hardware
        !            59: directly than kernel code,
        !            60: as it is much easier to debug user processes than kernel code.
        !            61: .PP
        !            62: The current X implementation uses a TCP stream both locally and
        !            63: remotely, though one could easily use 
        !            64: .UX
        !            65: domain sockets for the local
        !            66: case at the cost of a file descriptor.
        !            67: For current applications, the bandwidth limitations (of approximately
        !            68: 1 million bits/second on 780 class processor) is not major,
        !            69: though faster devices (and image processing applications) would probably
        !            70: benefit from implementation of a shared memory path between the X server
        !            71: and client applications.
        !            72: .PP
        !            73: Current shared memory implementations in variants of 
        !            74: .UX
        !            75: are not sufficient.
        !            76: Memory sharing primitives should allow appropriately
        !            77: privileged programs to both share memory with other processes and map to
        !            78: both kernel space and I/O space.
        !            79: Shared libraries (available in some versions of 
        !            80: .UX )
        !            81: would also increase the options available to window system
        !            82: designers (see below).

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