Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!think.com!ames!sun-barr!olivea!uunet!pipex!demon!grendel.demon.co.uk!jes From: jes@grendel.demon.co.uk (Jim Segrave) Newsgroups: comp.unix.bsd Subject: Re: DMA disk controllers Message-ID: <720533928snx@grendel.demon.co.uk> Date: 31 Oct 92 05:18:48 GMT References: <1992Oct27.185316@eklektix.com> Sender: usenet@gate.demon.co.uk Organization: None Lines: 71 ReplyTo: jes@grendel.demon.co.uk X-Mailer: cppnews $Revision: 1.19 $ In article <1992Oct27.185316@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes: > jes@grendel.demon.co.uk (Jim Segrave) writes: > >[I wrote] > >> There are two buses to consider: I/O and memory. DMA can't take over the > >> memory bus, because it can only feed it via the I/O bus, which is much > >> slower. Therefore, the CPU can sit and crank in memory while data dribbles > >> in/out. > >ISA machines do both memory and I/O down the same bus. > > I hate to do one of these "is so!"--"is not!" exchanges, but this is just > plain wrong. We *are* talking about 386 machines, right? 386 ISA-bus > machines are built with an I/O bus, which is the good ol' 16-bit-wide > 24-bit-address "AT bus" AND a separate interconnection between the CPU and > memory. This separate interconnect will be 32 bits wide (except for 386SX > systems), will be much faster, and these days will commonly have more than > 24 address bits. There are two separate buses. Sorry, I expressed it badly. I know that 386/486 machines have multiple busses, but they all reduce to a single bus at the CPU, and this bus is tri-stated when DMA takes place. The fact that the bus is later split to give 32 bit connections to RAM and a slowed down ISA peripheral bus makes no difference to DMA. No CPU initiated memory or I/O cycles take place until the DMA controller releases. Even if the DMA controller were moving data between two cards on the ISA bus, the CPU would not be allowed to access motherboard ram during the DMA cycles. > [ObHistory: 286 ATs are generally built to have memory and peripherals on > the same bus, the ISA bus. There were a few early 386 designs that worked > that way, mostly as quick interim solutions to get 386 machines out. I > don't know of any such machines built within the last four years. It > should be obvious that you don't feed a 32 bit CPU with a cycle time from > 67 down to 20 ns via a bus that can only deliver 16 bits every 375 ns!] > 70 ns ( See above - it doesn't matter that there are faster CPU<->memory connections, when DMA is going, you can't use the local connections. > >> I'm not convinced the 8237 can drive the I/O bus to capacity, either. I > >> believe that even when it's running flat-out, and even after taking bus > >> arbitration into account, there are still I/O bus cycles available... > .... > >No, when a DMA controller is in burst mode (which would be the mode used > >for disc and network controllers where the data to be moved resides in > >or is going to a memory buffer on the controller), the bus is completely > >seized by the DMA controller for the duration of the transfer. There are > >no CPU cyles left. > > I know how burst-mode DMA works. But I'm not talking about any old DMA > controller and bus. I'm talking about the 8237 (well, OK, the 8237A-5 > [fast version] or equivalent) on the ISA bus. The claim is that the 8237 > can transfer 1.6 MB/sec. The ISA bus is capable of 5.3 MB/sec. THAT is > why I think there should be bus cycles left over. If you're claiming that > the overhead takes the other 70% (!) of bus bandwidth, it would be nice to > see a sketch of timing to prove it. (I could believe it...I've seen > stranger things...but I won't accept it on faith.) There is unused capacity. The hardware doesn't let you get at it. It is true that performance would be improved by not using burst mode, but the hardware, particularly 8237 derirvative DMA controllers, is ill set up for anything but single transfer and burst mode. Ideally short bursts of a few bytes at a time would be best. > >> And, as someone else already mentioned, you may be able to reduce interrupt > >> overhead using DMA. > .... > >...the reduction in interrupts will be by page > >size/sector size - about an 8 to 1 reduction. This will produce a slight > >performance edge, but nothing very significant. > > Excuse me? An 8:1 reduction in interrupts isn't significant??? I can't > fathom a reason for this statement. because I doubt that the ISR activity will represent a large proportion of the CPU usage for Unices. It would have a large impact on raw disc throughput for large reads like initial boot up, but, in normal use, the code for handling disc blocks, checking the buffer cache,copying blocks from the buffer cache to user space, etc will swamp the time spent in all but the most horrifically ill-written ISR. -- Jim Segrave (Segrave Software Services) jes@grendel.demon.co.uk