On Sat, Jan 25, 2003 at 11:43:40PM +0000, Dave Mitchell wrote: > On Sat, Jan 25, 2003 at 06:18:47AM -0800, Sean O'Rourke wrote: > > On Sat, 25 Jan 2003, Leopold Toetsch wrote: > > > Dan Sugalski wrote: > > > > > > > At 5:32 PM +0000 1/24/03, Dave Mitchell wrote: > > > > > > > >> I just wrote a quick C program that successfully mmap-ed in all 1639 > > > >> files in my Linux box's /usr/share/man/man1 directory. > > > > > > > > > > > > Linux is not the universe, though.
There's always NetBSD if Linux won't run on your hardware :-) <ducks> > > How true. On Solaris, for example, mmap's are aligned on 64k boundaries, > > which leads to horrible virtual address space consumption when you map > > lots of small things. If we're mmap()ing things, we want to be sure > > they're fairly large. > > Okay, I just ran a program on a a Solaris machines that mmaps in each > of 571 man files 20 times (a total of 11420 mmaps). The process size > was 181Mb, but the total system swap available only decreased by 1.2Mb > (since files mmapped in RO effecctively don't consume swap). 11420 simultaneous mmaps in the same process? (just checking that I understand you) > I think Solaris and Linux can both cut this. If other OSes can't, then > we fallback to reading in the file when necessary. Maybe I'm paranoid (or even plain wrong) but we (parrot) can handle it if an mmap fails - we just automatically fall back to plain file loading. Can dlopen() cope if an mmap fails? Or on a platform which can only do a limited number of mmaps do we run the danger of exhausting them early with all our bytecode segments, and then the first time someone attempts a require POSIX; it fails because the perl6 DynaLoader can't dlopen POSIX.so? (And by then we've done our could-have-been-plain-loaded mmaps, so it's too late to adapt) Nicholas Clark
