From owner-freebsd-hackers Wed Feb 17 12:21:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 474EB112CA for ; Wed, 17 Feb 1999 12:20:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA10702; Wed, 17 Feb 1999 12:20:50 -0800 (PST) (envelope-from dillon) Date: Wed, 17 Feb 1999 12:20:50 -0800 (PST) From: Matthew Dillon Message-Id: <199902172020.MAA10702@apollo.backplane.com> To: Kevin Day Cc: dyson@iquest.net, tlambert@primenet.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill References: <199902172005.OAA29252@home.dragondata.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :logic analyzer is a form of witchcraft... If this is the case, turning this :> :off would greatly help me. :) :> :> It should not be zeroing pages before doing full reads into them. :> That is pretty well optimized, usually. : :What if I'm doing a partial read? Is a partial read even possible if I'm :using the mmap method? The filesystem always does a full read even if you only do a partial read. This is true whether you use read() or access a page w/ mmap(), but it is doubly true with mmap(). :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. You would have to design a device to do it. Not terrible, but not trivial either. But that wouldn't get rid of the memcpy... the only way to get rid of the memcpy is to make the filesystem write the data from the file directly to the frame buffer by supplying ficticious pages directly to the underlying block device. This would be a difficult hack to do in the filesystem, but you might be able to do it talking to a raw device and not have to hack the system at all. For example, create a partition on the hard disk that you intend to access directly. i.e. no filesystem. If you mmap() the frame buffer, and issue a read() on the raw device interface for the partition with a pointer into the mmap()'d frame buffer, I *believe* this will result in direct DISK->PCI DMA. I'm not positive, though. :> 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. :) It is a DMA capable IDE controller, right? If not, you are S.O.L. :Thanks, : :Kevin -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message