Date: Wed, 17 Feb 1999 15:04:01 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Kevin Day <toasty@home.dragondata.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, dyson@iquest.net, tlambert@primenet.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill Message-ID: <Pine.BSF.3.95.990217145536.15285M-100000@current1.whistle.com> In-Reply-To: <199902172005.OAA29252@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Feb 1999, Kevin Day wrote: > > > > > Third, Memory->PCI transfers are best done with DMA ( as you > > already know ). For a frame store, you can eek out additiona > > l PCI bus speed by messing with the burst transfer length ( > > especially if the cpu is not heavily involved and can afford > > to stall a little more ). You should be able to push > > 120 MBytes/sec on a PCI bus by tuning the DMA burst. > > The PCI card should have a FIFO big enough to accomodate the > > burst, too. If you do a large transfer to a PCI card's frame > > buffer with memcpy() ( or equivalent ), you eat double the > > memory bandwidth plus blow away the data cache on the cpu. > > I tried this, but ran into a few problems. > > First, I had to somehow convince the vm system to bring the pages in from > disk, before doing the DMA, and making sure they were contiguously mapped to > physical ram, and then forcing it not to dump them later. Never quite got > past this hurdle. :) Is there a driver somewhere that does this? In my > system, userland code mmap()'s data, and does memcpy's to a mmaped device > that corresponds directly to the physical frame buffer. I wasn't really sure > how to make sure the data ended up in a nice contiguous buffer to DMA it out > of, without doing another copy. Is the data on raw disk or in files? if on raw disk then: 1/ create a device called "/dev/bufferspace" this should allocate a N MB sequential buffer of reserved memory when the system boots. 2/ do all reads from the raw device. straight into this space. The VM system will step out of the way and let the DMA do all the work. (I assume you are using UltraDMA on your IDE drives right?) store the data on raw partitions using your own user level filesystem e.g. a simple system where working out where to look for the data is done by a library you lik with rather than a filesystem in the kernel. Use reads and writes to the raw disk devices to read the data. this is blazingly fast, and you should be able to use the aio stuff or the kernel thread stuff to 'preread' teh data in before you need it and to allocate the space in your static buffer. If you are reading files from a filesystem in the kernel then things get messier. Do you have to rewrite the data to disk? can they be read-only? etc.etc. > > Also, just in a non-working test case, it actually seemed slower doing it > this way, and I lost interest at this point. :) > > > > > Fourth, if you are doing direct frame store from disk to a > > PCI card, you may wish to consider building a custom piece > > of hardware / firmware to actually use the SCSI bus to > > transfer the data directly ( i.e. put the frame store *on* > > the SCSI bus and have it master the data directly from the > > drives without host intervention ). This is a rather more > > complex solution. > > We're using IDE too. :) > > > > Thanks, > > Kevin > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990217145536.15285M-100000>