Date: Thu, 15 May 1997 14:44:33 -0400 From: "David S. Miller" <davem@jenolan.rutgers.edu> To: terry@lambert.org Cc: terry@lambert.org, ejc@bazzle.com, james@westongold.com, freebsd-hackers@FreeBSD.ORG Subject: Re: mmap() Message-ID: <199705151844.OAA01311@jenolan.caipgeneral> In-Reply-To: <199705151821.LAA15353@phaeton.artisoft.com> (message from Terry Lambert on Thu, 15 May 1997 11:21:25 -0700 (MST))
next in thread | previous in thread | raw e-mail | index | archive | help
From: Terry Lambert <terry@lambert.org> Date: Thu, 15 May 1997 11:21:25 -0700 (MST) The intelligent mechanisms generally require a history with the file; The ICON systems (which used a seperate processor for the disk controller subsystems) kept a bitmap of this information to decide which pages were probably going to be asked for, and faulted them in. The one I have made reference to only requires a small learning prefetch tree to be hung off the vnode, after you acquire a certain amount of "learning codes" you just chuck the entire tree and begin learning again (this guarentees that bad sequence code selections eventually get kicked out, it also limits how much space your learning tree can ever take up). The University of Utah, in particular, had a very interesting project which involved keeping around pieces of prelinked PIC objects, which was effectively "faulting" object linking for shared libraries. They unfortunately required you to do bizarre things with your address space (I considered it as a potential candidate for BSD shared libraries at one time). Solaris and IRIX both do something remotely like this, it's a very old idea but can be applied to existing binary formats like ELF. (one thing they do is they assign a "probably gonna mmap() is here" address to every single shared library, and they distribute the address space as evenly as they can amongst these libraries, thus they pre-relocate all the symbols assuming this address, then when a program maps it in they try hard to use the pre-relocated address, they even do this for what will be the anonymous mapped bss section for the library). Solaris has even better tricks where they collapse all the symbols you actually have referenced in a shared library into one spot, so for example if you only reference printf(), write(), and read(), those three libc calls get collapsed into one page. It's a tlb/cache miss prevention thing, but the implementation is a bitch. Solaris also has symbol versioning, a very powerful concept to prevent having to make old interfaces obsolete in a new libc release for example, we support this particular facility under Linux (although in a more powerful form, Solaris got the concept right but they fucked up a lot of the important details, making they symbol versioning pretty much useless in numerous important cases). I seems to me that the cache criteria algorithm from this would be a good method for intelligent page selection... it's basically the same thing, applied to code usage rather than data usage of the page contents, and the bonus is that it's published instead of patented. Patented does not mean the idea is not usable, you can only patent a specific implementation, just change one of the variables in the implementation (in the case of the prefetching algorithm I referenced, just change the compression code scheme to some other one which is just as suitable) and you're safe. ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705151844.OAA01311>