From owner-freebsd-current@FreeBSD.ORG Mon Jun 21 22:59:42 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 DFD5916A4CE; Mon, 21 Jun 2004 22:59:42 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C078243D41; Mon, 21 Jun 2004 22:59:42 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i5LMxXx7036548; Mon, 21 Jun 2004 15:59:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i5LMxX1l036547; Mon, 21 Jun 2004 15:59:33 -0700 (PDT) (envelope-from dillon) Date: Mon, 21 Jun 2004 15:59:33 -0700 (PDT) From: Matthew Dillon Message-Id: <200406212259.i5LMxX1l036547@apollo.backplane.com> To: Dan Nelson References: <200406211057.31103@aldan> <200406211952.i5LJqWSl035702@apollo.backplane.com> <200406211810.03629@misha-mx.virtual-estates.net> <20040621222631.GC86471@dan.emsphone.com> cc: Mikhail Teterin cc: questions@freebsd.org cc: Julian Elischer cc: Mikhail Teterin 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: Mon, 21 Jun 2004 22:59:43 -0000 : :ask for 8k, but the system will fetch the next 64k of data. Problem is :the system does nothing until you read the next 8k past the 64k :alreqady read in, then it jumps up and grabs the next 64k. You're :still waiting on I/O every 8th read. Ideally it would do an async :.. :-- : Dan Nelson : dnelson@allantgroup.com No, this isn't true. The system places a marker 8K or 16K before the last read block and initiates the next read-ahead before you exhaust the first one. For mapped data the system intentionally does not map the page table entry for a page or two before the end of the read ahead in order to force a page fault so it can initiate the next read ahead. For read data the system marks a buffer near the end of the read ahead so when read encounters it the system knows to queue then next read-ahead. Also, for that matter, remember that the hard drives themselves generally cache whole tracks and do their own read-ahead. This is why dd'ing a large file usually results in the maximum transfer rate the hard drive can do. -Matt Matthew Dillon