From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 4 21:20:46 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE6931065672 for ; Tue, 4 Mar 2008 21:20:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outC.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id BA3EB8FC1F for ; Tue, 4 Mar 2008 21:20:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 04 Mar 2008 13:20:46 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id C8E1C2D6023; Tue, 4 Mar 2008 13:20:45 -0800 (PST) Message-ID: <47CDBD2D.3010103@elischer.org> Date: Tue, 04 Mar 2008 13:20:45 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Robert Watson References: <200803022218.32873.cneirabustos@gmail.com> <20080303081021.GC80576@hoeg.nl> <47CC6E7D.10707@elischer.org> <20080304150904.R41184@fledge.watson.org> In-Reply-To: <20080304150904.R41184@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: readahead(2) - Linux X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 21:20:46 -0000 Robert Watson wrote: > On Mon, 3 Mar 2008, Julian Elischer wrote: > >> Ivan Voras wrote: >> >> the aim is to load it into system memory but not copy anything into >> user memory. > > In an ideal world (tm), a prefetch system call doesn't actually force > the I/O to happen, it just hints that if it did happen, life would then > be better. Then, in said ideal world (tm), the VM system can juggle > investing pages in memory and I/O capacity in heuristic read-ahead, > prefetch hints from the application, anonymously process memory, and > buffer cache, based on what is most effective for particular > applications or workloads. Last time I read up on I/O prefetching > literature, it was considered quite difficult to place prefetch calls in > applications in a useful way, and that normal heuristic read-ahead, > which we already support, actually caught a high percentage of real > application cases since applications do tend to order and store data > usefully in files. For certain applications, though, that doesn't help > much, and there isn't a way to tune "up" read-ahead prefetching, so it > could be we're no longer doing as good a job. The assumption is that the application has a clue as to what it wil need in the near future and is explicitly hinting to the kernel to queue it for reading. The equivalent would be to do something like an madvise on a mmapped version of the file assuming that madvise can ask for a page to be faulted in without blocking for it.. The key is that the process must not block when issuing the request, as it doesn't want to wait for the data.