From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3C165ECF.6E0AACCA@null.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200112102218.IAA08394@hadrian.staff.apnic.net>, <3C15E692.18FA79CB@strakt.com> Subject: Re: [9fans] RDMA: DMA over TCP/IP at IETF Date: Wed, 12 Dec 2001 09:47:25 +0000 Topicbox-Message-UUID: 337be2a0-eaca-11e9-9e20-41e7f4b1d025 Boyd Roberts wrote: > Some versions for the VAX mapped the UNIBUS address space > smack on top on the clists so if you had tty h/w that could > DMA (the DZ-11? or did you need KMC's for that?) you wouldn't > have to map the UNIBUS for each DMA. This was a grody hack, > but the alternatives were just too slow, particularily if > you wanted to support 128 students on a '780. My bet would be the KMC11-B; that was a nice hardware hack. The DZ11 didn't do DMA (but some other multiplexers did); I think one of the available DZ11 drivers had "pseudo DMA" to unify it with the other drivers. So far as I know the only DZ11 driver that had decent throughput was the one I wrote (originally for 6th Ed.); as a reminder the DZ11 had a small (32 char?) silo and interrupted when silo service was requested, BUT after moving data to/from the silo the "silo service request" flag was not set again even if it logically should be, for something like 30us, and typical drivers even though they were testing the silo before returning from interrupt were just not waiting long enough, with the effect that there was a separate interrupt service for *every* char. My solution was to burn up those 30us before testing, which might seem wasteful but actually paid off big time. > Mapping it into user mode is a real can of worms; not only is > it highly unportable it really messes up the memory management > because pages have to be locked. Locking is a nightmare; don't > lock and you lose, have too many locks and horrible bugs appear > either immediately [bad] or months/years later [worse]. I don't think there are any inherent problems. We've been locking disk inodes for eons.