From owner-freebsd-hackers Tue Oct 28 03:06:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA14952 for hackers-outgoing; Tue, 28 Oct 1997 03:06:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA14945 for ; Tue, 28 Oct 1997 03:06:52 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id DAA10220; Tue, 28 Oct 1997 03:06:47 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id DAA07759; Tue, 28 Oct 1997 03:06:46 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id DAA25277; Tue, 28 Oct 1997 03:06:45 -0800 (PST) From: Don Lewis Message-Id: <199710281106.DAA25277@salsa.gv.tsc.tdk.com> Date: Tue, 28 Oct 1997 03:06:45 -0800 In-Reply-To: Dave Andersen "Re: help with fstat?" (Oct 26, 7:58pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Dave Andersen , Alfred Perlstein Subject: Re: help with fstat? Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Oct 26, 7:58pm, Dave Andersen wrote: } Subject: Re: help with fstat? } > i don't want to exhaust the virtual memory on the machine, just get } > optimal transfers. } } mmap will give you optimal transfers since you won't have the } additional overhead of additional memory copies inside your machine. Actually it really depends on the OS. There's no reason the OS can't avoid memory to memory copies when reading a file if you use a page aligned buffer and read multiples of the page size. The kernel can just fiddle with the page table for the process to map pages from the buffer cache into the user space with the copy-on-write flag set. If the kernel is smart enough to detect that the process is doing sequential reads and the process is consuming the data more slowly that it can be read from disk, it may be possible for the kernel to perform readahead so that it always has the next chunk of data from the file loaded into the buffer cache before the process asks for it so that the process never blocks waiting for the disk. One variation I've seen DMAs data directly from the disk into user space on large enough requests, bypassing the buffer cache. Another doesn't actually copy the data into user space during the read() call, but page faults it in as the buffer is accessed. If you mmap the file, the process may block each time a new page is accessed to allow that page to be faulted in from the disk. Of course the kernel may still be able to do readahead to avoid blocking the process if the kernel is able to detect that the process is accessing the pages sequentually.