Date: Mon, 19 Jun 1995 02:31:40 +0800 (WST) From: Peter Wemm <peter@haywire.DIALix.COM> To: hackers@freebsd.org Subject: benchmarks, shared libs, optimizations etc Message-ID: <Pine.SV4.3.91.950516062340.16341E-100000@haywire.DIALix.COM>
next in thread | raw e-mail | index | archive | help
[Note: this is an old message that has been sitting around for a few weeks waiting to be sent. It was about the time when the "Why Linux benchmarks faster than freebsd" threads. Oh well. here it is anyway... Please bear in mind that it was "thinking aloud" - I offer it only as food for thought, I'm not advocating some suggestion that we must change it this way.] I've been thinking about some of the shared library loading issues kinda on the back-burners for the last week or so. I just thought I'd mention some of the ideas.. Linux has a special system call to load a shared lib, and it understands both linux-a.out and linux-elf formats. As I understand it, the kernel allocates some fixed address space, which it uses for all subsequent processes that use the same library. This has some advantages: 1: It can share the page tables in that area during a context switch, making it faster. 2: PIC can be done away with, or it can be relocated just once. 3: library attaches for new processes can be rather quick, as it probably wont relocate or modify page tables. 4: It's just about as fast using sun-style shlibs (a.out or elf) as it is with static SVR3-style libs. [re note 3: what I meant whe I wrote that, was that the loader could relocate it once and use the same addresses continuously, with no need to copy-on-write it in each address space, and no need to make pic references to the data section] Anyway, freebsd uses mmap() (as do sun, svr4, etc) to pull the file into a different virtual address on each invocation, reloacates each time, and so on. The freebsd system could be modified, quite transparently, and without breaking anything, and without needing a new syscall. (Remember, I'm just tossing ideas around..I know there are problems). OK.. Add a new flag to mmap.. Say MAP_SHLIBCACHE. When ldconfig is run at bootup, it goes through the entire library path, and because it's euid = root, it gets the kernel to allocate some fixed, persistant address space for the library. ldconfig could relocate the code and/or maybe allocate some space for the global offset tables (in swap, ram or some file.. whatever). I'm not suggesting that they be locked into memory.. Just allocate the space. Then, a user process, calling mmap(), can have it intercepted by the kernel noticing the same vnode, and can link the existing pages to the address space. If the relocation has been done in the image that it gets, then it's finished, and needs not much more initialisation . Doing it this way allows new or replaced, or custom libraries to work transparently. The only thing that's changed is that the pre-configured objects are pre-configured. It might be that global offset tables might need to be pre-relocated and saved somewhere by ldconfig (/var/run/ld.so.got) and also "cached" via mmap() too. I have not thought too much about that.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.91.950516062340.16341E-100000>