From owner-freebsd-hackers Sat Apr 22 10: 6:58 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id DF0A237B540 for ; Sat, 22 Apr 2000 10:06:48 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA55294; Sat, 22 Apr 2000 10:06:38 -0700 (PDT) (envelope-from dillon) Date: Sat, 22 Apr 2000 10:06:38 -0700 (PDT) From: Matthew Dillon Message-Id: <200004221706.KAA55294@apollo.backplane.com> To: Alfred Perlstein Cc: Kevin Day , hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) References: <200004220255.VAA29433@celery.dragondata.com> <20000422012005.A204@fw.wintelcom.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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. :) : :-- :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Probably not so good considering the number of faults that will be taken. Also, if the destination filesystem runs out of room cp will take a random seg-fault trying to access the map. Plus the dirtying of that many VM pages will seriously effect performance. 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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message