Date: Fri, 18 Apr 1997 12:57:51 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: dufault@hda.com, hasty@rah.star-gate.com, terry@lambert.org, freebsd-hackers@freebsd.org Subject: Re: video capture driver interface to file system? Message-ID: <199704181957.MAA02638@phaeton.artisoft.com> In-Reply-To: <199704181021.MAA08439@labinfo.iet.unipi.it> from "Luigi Rizzo" at Apr 18, 97 12:21:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Pre-allocate the file; pre-allocate the blocks of a file; pre-set > > up some control info for a transfer, mmap a set of blocks for the > > video card driver to dump data into; have the driver chain to the > > next block and interrupt you on each transfer, dump the video frames > > to the pre-allocated store. > > and probably, in addition to preallocation, make sure that your write() > calls are aligned to the FS/device blocksize otherwise (probably) each > write will be preceeded by a hidden read to take care of fragmentation ? Actually, the block mapping overhead is higher if you aren't on a page multiple boundry and not a page size; that appears to be the fastest path in the VM code. Otherwise you end up manipulating multiple mappings for each operation. Follow /sys/kern/vfs_bio.c, specifically down through vfs_busy_pages() into the bowels of the VM system for details. I think in some very specific-use circumstances, the best bet would be a 4k FS block size. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704181957.MAA02638>