Path: utzoo!utgpu!cunews!cognos!alzabo!andras
From: andras@alzabo.ocunix.on.ca (Andras Kovacs)
Newsgroups: comp.sys.acorn
Subject: Re: MEMC and video DMA question
Message-ID: <1991Feb15.120720.22437@alzabo.ocunix.on.ca>
Date: 15 Feb 91 12:07:20 GMT
References: <1277@culhua.prg.ox.ac.uk>
Reply-To: andras@alzabo.UUCP (Andras Kovacs)
Organization: Brian's XENIXlings, Ottawa, Canada
Lines: 47

In article <1277@culhua.prg.ox.ac.uk> as@prg.ox.ac.uk (Andrew Stevens) writes:
>In a basic Arch you get contention between the video-subsystem and the
>CPU - the MEMC multiplexes the two onto the same memory sub-system.  It
>even generates the video-DMA addresses as I understand it. So, what
>happends in a machine with 2 or more MEMC's?
>
>Can you fix things up so that RAM controlled by one MEMC supports video
>DMA (and runs slow), whilst a second bank with its own MEMC runs at full
>tilt.  In an A540, for example, does the machine run faster when more
>than one RAM bank is added?

    "A single MEMC will control up to 4M bytes of DRAM. A second MEMC can be
built into a system to extend the maximum addressable DRAM to 8M bytes. The two
MEMCs are configured as a Master and a Slave, where the Slave acts purely as a
DRAM driver (all DMA operations, I/O controller interactions, etc. are handled
by the Master)." (VL86C010 book from VLSI, Inc.)

>Also, does MEMC support general-purpose DMA as well as video?
>E.g. for winchesters etc, or is all that sort of stuff (as I
>heard rumoured) done by the main CPU?

    It seems to me that there is no general-purpose DMA in the MEMC; I think
the designers thought that with the extra overlapping regs in FIQ mode, you
can emulate a DMA channel quite efficiently.

>The latter would at least partially explain the reputedly poor
>through-put of Rxy0 UNIX systems when paging.  A 32K page size certainly
>doesn't help, but it shouldn't impact through-put all that much. If the
>system isn't thrashing other runnable processes should happily soak up
>CPU time while a page-fault is fixed.  However, if the CPU was *busy*
>during page-faults sluggish performance during paging would be no
>suprise at all.

    I am afraid that the 32K page size indeed a poor choiche in a demand-paged
virtual memory system; my understanding is (from the stuff floating on comp.
sys.arch) that in order to provide half-decent performance, you have to have
~4KB page sizes. Also, 'cause the MEMC does not provide statistical info about
the pages (dirty bit, # of hits) write-back and good page-fault replacement
strategy is a problem. Anyone could shed more light on this aspect?

>Andrew

    Andras
-- 
Andras Kovacs 
andras@alzabo.ocunix.on.ca
Nepean, Ont.