From owner-freebsd-current@FreeBSD.ORG Sun Jun 20 16:52:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC72516A4CF; Sun, 20 Jun 2004 16:52:38 +0000 (GMT) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 648F343D53; Sun, 20 Jun 2004 16:52:38 +0000 (GMT) (envelope-from mi@aldan.algebra.com) Received: from aldan.algebra.com (mi@localhost [127.0.0.1]) by aldan.algebra.com (8.12.11/8.12.11) with ESMTP id i5KGqIeM027990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jun 2004 12:52:18 -0400 (EDT) (envelope-from mi@aldan.algebra.com) Received: by aldan.algebra.com (8.12.11/8.12.11/Submit) id i5KGqHuu027988; Sun, 20 Jun 2004 12:52:17 -0400 (EDT) (envelope-from mi) From: Mikhail Teterin To: Dan Nelson Date: Sun, 20 Jun 2004 12:52:14 -0400 User-Agent: KMail/1.6.2 References: <200406200343.03920@aldan> <20040620154120.GC5040@dan.emsphone.com> In-Reply-To: <20040620154120.GC5040@dan.emsphone.com> X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" X-Mailman-Approved-At: Mon, 21 Jun 2004 11:53:21 +0000 cc: questions@freebsd.org cc: current@freebsd.org Subject: Re: read vs. mmap (or io vs. page faults) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 16:52:38 -0000 On Sunday 20 June 2004 11:41 am, Dan Nelson wrote: = In the last episode (Jun 20), Mikhail Teterin said: = > I expected the second way to be faster, as it is supposed to avoid = > one memory copying (no user-space buffer). But in reality, on a = > CPU-bound (rather than IO-bound) machine, using mmap() is = > considerably slower. Here are the tcsh's time results: = MADV_SEQUENTIAL just lets the system expire already-read blocks from = its cache faster, so it won't help much here. That may be what it _does_, but from the manual page, one gets an impression, it should tell the VM, that once a page is requested (and had to be page-faulted in), the one after it will be requested soon and may as well be prefeteched (and the ones before can be dropped if memory is in short supply). Anyway, using MADV_SEQUENTIAL is consintently making mmap behave slightly worse, rather then have no effect. But let's not get distracted with madvise(). Why is mmap() slower? So much so, that the machine, which is CPU-bound using read() only uses 90% of the CPU when using mmap -- while, at the same time -- the disk bandwidth is also less than that of the read(). It looks to me, like a lot of thought went into optimizing read(), but much less into mmap, which is supposed to be faster -- less memory shuffling. Is that true, is there something inherent in mmap-style of reading, that I don't see? = read() should cause some prefetching to occur, but it obviously = doesn't work all the time or else inblock wouldn't have been as high = as 11000. For sequential access I would have expected read() to have = been able to prefetch almost every block before the userland process = needed it. Thanks! -mi