Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) (10/28/90)
>>>>> 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!chuckpjpk@ingres.com (Jon Krueger) (10/30/90)
From article <CHUCK.PHILLIPS.90Oct28010826@haydn.FtCollins.NCR.COM>, by Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips): > [mmap] 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. Engines that support formal data models, ad hoc queries, and atomic, serializable, permanent transactions have performance characteristics that are not typically bottlenecked on the simple costs of loading data from disk to memory. Or, mmap ain't gonna save you in the real world. Might help under certain circumstances: sparse addressing, large ratio of reads to writes, page size not far from data element size. -- Jon Not speaking for anyone but myself. -- Jon Krueger, jpk@ingres.com