Date: Sat, 22 Apr 2000 13:23:40 -0400 (EDT) From: Michael Bacarella <mbac@nyct.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Alfred Perlstein <bright@wintelcom.net>, Kevin Day <toasty@dragondata.com>, hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) Message-ID: <Pine.BSF.4.21.0004221320250.38433-100000@bsd1.nyct.net> In-Reply-To: <200004221706.KAA55294@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> :extend (using truncate) and then mmap() the destination file, then > :read() directly into the mmap()'d portion. > : > :I'd like to see what numbers you get. :) > read + write is a better way to do it. It is still possible to > double buffer. In this case simply create a small anonymous shared > mmap that fits in the L2 cache (like 128K), setup a pipe, fork, and > have one process read() from the source while the other write()s to the > destination. The added overhead is actually less then 'one buffer copy' > worth if the added buffering fits in the L1 or L2 cache. It seems silly to implement something as trivial and straightforward as copying a file in userland. The process designated to copy a file just sits in a tight loop invoking the read()/write() syscalls repeatedly. Since this operation is already system bound and very simple, what's the arguement against absorbing it into the kernel? -MB 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.4.21.0004221320250.38433-100000>