From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 4 15:12:48 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 088241065674; Tue, 4 Mar 2008 15:12:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A423E8FC21; Tue, 4 Mar 2008 15:12:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id AA4DF46B10; Tue, 4 Mar 2008 10:12:46 -0500 (EST) Date: Tue, 4 Mar 2008 15:12:46 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <47CC6E7D.10707@elischer.org> Message-ID: <20080304150904.R41184@fledge.watson.org> References: <200803022218.32873.cneirabustos@gmail.com> <20080303081021.GC80576@hoeg.nl> <47CC6E7D.10707@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 15:12:48 -0000 On Mon, 3 Mar 2008, Julian Elischer wrote: > Ivan Voras wrote: >> Ed Schouten wrote: >>> * carlos neira wrote: >>>> is there an equivalent of readahead syscall in linux , for freebsd ?. i >>>> was looking at http://preload.sourceforge.net/ , and it needs this . >>> Maybe a mmap(), followed by a madvise()? >> >> Or an open() followed by a read() loop? :) If the goal is to preload the >> files, this one is certainly going to do it :) > > 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. Robert N M Watson Computer Laboratory University of Cambridge