Path: utzoo!attcan!uunet!ncrlnk!ncr-mpd!Chuck.Phillips From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) Newsgroups: comp.arch Subject: Memory mapping persistant data (was: >32 bits) Message-ID: Date: 28 Oct 90 00:08:26 GMT References: <1990Oct25.011034.3664@ingres.Ingres.COM> Sender: uucp@ncr-mpd.FtCollins Organization: NCR Microelectronics, Ft. Collins, CO Lines: 37 In-reply-to: jpk@ingres.com's message of 25 Oct 90 01:10:34 GMT >>>>> On 25 Oct 90 01:10:34 GMT, jpk@ingres.com (Jon Krueger) said: Jon> Just to play devil's advocate, why use the processor to address Jon> persistent, shared data objects? How about avoiding the _necessity_ of a context switch to grab a new record? In UNIX, all system calls require a trap plus two context switches, and all I/O is done ultimately via system calls. (i.e. trap, switch to "supervisor" mode, context switch into kernal code, jump into device driver code, return from driver code, return to "user" mode, context switch back to user code, not necessarily in that order) EXCEPTION: Using mmap(), one takes the unavoidable system call overhead _once_ to map a file into the process space. After that, you're only penalized for page faults and the usual multitasking context switches. (How's that for painless on-demand loading of data? ;^) I suspect a DB engine under UNIX could see some significant performance improvement by leveraging off mmap() et al instead of attempting to duplicate it. (Hint, hint. :-) Unfortunately, mmap() to my knowlege, only has been _fully_ implemented under SunOS 4.x and SVr4, although other memory mapping mechanisms are available under other OS's. (Rumor time: Last I heard, mmap() et al was the subject of considerable debate for inclusion in POSIX, but I haven't heard the outcome. I've also heard OSF will include some sort of memory mapping capability, possibly mmap(), but I don't _know_. Rx: Take this with a large grain of salt. Corrections welcome.) If there's someone out there using mmap() for high-performance DB access, I'd like to hear of your experiences. References also welcome. I'll post a summary if requested (and if I get responses!). Disclaimer: Not in any way a spokesman for POSIX, UI, OSF or my company. -- Chuck Phillips MS440 NCR Microelectronics chuck.phillips%ftcollins.ncr.com 2001 Danfield Ct. Ft. Collins, CO. 80525 ...uunet!ncrlnk!ncr-mpd!bach!chuckp