Date: Mon, 24 Apr 1995 14:37:04 -0700 (PDT) From: John Dyson <dyson@Root.COM> To: terry@cs.weber.edu (Terry Lambert) Cc: toor@jsdinc.root.com, geli.com!rcarter@implode.root.com, hackers@FreeBSD.org, jkh@violet.berkeley.edu Subject: Re: benchmark hell.. Message-ID: <199504242137.OAA11761@Root.COM> In-Reply-To: <9504242008.AA19390@cs.weber.edu> from "Terry Lambert" at Apr 24, 95 02:08:11 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > my lmbench fork/exec tests (with our shared libs) on my 486/66 are fairly > > close to the example Linux Pentium results. But, our pipe performance could > > be better though. > > > First, this is a bogus benchmark set. Unless the benchmarks are run > on identical hardware, there are totally non-referential and are thus > meaningless. Not totally... It is okay for ballpark info. Benchmarks in general (other than the actual application that the machine is going to be used for) can be made to lie. > > A second issue in context switch is the TLB lookaside switchout. I > have to say that personnaly, I'd be happy with the UnixWare level of > performance in this area, because I believe the Linux stuff to be > extremely processer dependent. Nevertheless, it should be looked at. > It is extremely simple in FreeBSD, and is not significant. The page tables are pageable only if they are not used (empty.) All it takes is loading one of the CPU registers, and voila!!!! new address space!!! Except in conditions of significant paging, the page tables are there and ready to be used quickly. > > Part of the checking is to allow address faulting instead of precheck > comparison -- in other words, if the processer honors write protect in > protected mode, this becomes a NULL op. The magic here is that you > then only actually perform the check on i386 processers and not on > i486/i586. The memory mapping is adjusted so this works. > FreeBSD has depended on that off/on since before 1.1.5. We decided that a additional checks are a good idea, and have explicit diagnostics if the kernel causes unintended user-space page-faults. > > The final major advantage is the kernel premapping from where they > locate their processes in memory relative to the kernel, which allows > them to only partially change instead of fully changing the page > mappings. This means that they keep more per process info in core > than BSD. > The kernel is mapped by exactly the same page-tables for all processes. FreeBSD switches processes VM-wise by loading a new control register. No special copying is needed. Cloning the kernel part of a new process address space is done by copying the page directory entries directly into the new processes page directory. The kernel size in FreeBSD is dynamic, and can grow as needed (up to 256MB), special enhancements have been made to allow this and still maintain quick context switching from the VM perspective. > > On the shared libraries themselves, there should be preestablished > memory maps that can be copied instead of being reestablished for each > fork and for each exec that results in a shared library being loaded. > There is some bogosity in the way processes inherit their parents address space -- and we have been working that. I like the idea of standard addresses for shared libs also -- it opens up lots of possibilities for performance improvement. John dyson@root.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504242137.OAA11761>