Date: Fri, 15 Jan 1999 00:45:34 -0500 (EST) From: "John S. Dyson" <dyson@dyson.iquest.net> To: thorpej@nas.nasa.gov Cc: dyson@dyson.iquest.net, dillon@apollo.backplane.com, root@dyson.iquest.net, dg@root.com, jkh@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Review and report of linux kernel VM Message-ID: <199901150545.AAA19169@dyson.iquest.net> In-Reply-To: <199901150431.UAA08107@lestat.nas.nasa.gov> from Jason Thorpe at "Jan 14, 99 08:31:25 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > Anyhow, the copying of PTEs or whatever is precisely what pmap_copy() is > for, anyhow... and... > You are missing the point, and note that pmap_copy is only an obvious work-around for a small subset of the problem. It seems that those kinds of entry points were attempts (mostly in vain) to work around the pmap layering (and vm_fault) overheads. It seems to me (also) that vm_fault isn't quite at the right level -- at least a formal structure needs to be designed to support a fault mechanism that efficiently supports all types of processors. > > > However, if you look at the VM code, the issues of the layer transitions > > are significant. > > ...on these fancy RISC systems, the function calls are amazingly efficient > because the architecture doesn't suck nearly as bad as the x86 :-) > Why are alot (most) of those "fancy" RISC systems are actually slower than X86's :-)? Layer transitions cost relatively the same on current architectures -- I am not really interested in Vaxes, R3000's and 486's anymore. Sure, 486's are slow, but alot of the RISCs from that day were also slow. RISC systems do have that terrible overhead of macro instruction TLB mgmt, and that cost is often seen by those machines. Even though the benefits (better control, etc) are used as selling points, those "advantages" don't ever seem to provide value to anyone other than those who write sales brochures. However, all that said, I am working on a port of a TLB based RISC machine, and it will be fun :-). It seems to me the coolest thing about TLB-only MMUs is that they support variable page sizes. That is yet another challenge to take proper advantages of those capabilities (since TLB fills are often ugly, and it is good to minimize those, if you can at low cost.) I don't think that work on the current MACH code will go very far to optimize the use of TLBs (only alittle can be done in that structure), but a future VM system will be able to do a little more.) > > > It is clear that there is *something* wrong with the place where the > > layering is between the upper and lower level VM code. I am not sure > > where to put it though. > > Hm, why not spell out all the things that are wrong with it? Specifics, > John, specifics. And, also, please use sentences that make sense :-) > The things wrong with it are obvious -- too many layer transitions. RISC vs. CISC isn't the issue here. If you speak of pmap_copy, you are speaking of one optimization, but miss alot of the really wasteful VM system to pmap calls. I fixed alot more than just pmap copy (in fact, if you remove it from FreeBSD, you'll notice only a small performance difference.) The rest of the fixes vastly outweigh the pmap copy, preloading of pte's, and other such optimizations that are obvious, but only marginally valuable (in the scheme of things.) Actually, pmap_copy is MUCH MUCH less valuable on X86 architectures than preloading ptes. Now I am looking at "design" issues and far far beyond discussing minor implementation issues such as pmap_copy. > > "...the place where the layering is between the upper and lower level..."? > Jason, I guess you want to criticize me? :-). Maybe you cannot parse it, but you do understand? The place where the layering is, is not ideal (from a performance or even architectural standpoint.) I really am not sure where to split the machine dependent and machine independent layers yet in a new, re-thought out and modular VM system. There are aspects of current VM systems, including the inability to properly (cleanly) handle limited feature sets for (perhaps) embedded apps, that just need rethinking. I think that it is important to visit the problem again, divorcing onself from the arrogance associated with ownership of previous work, or arrogance associated with previous competition. Mostly, in this discussion, there is a statement of obvious problem, but the solution (and even the full formulation of the problem) needs to be thought about (probably iteratively.) I haven't seen an excellent VM system (ever), either commercial or free. That statement also includes FreeBSD's (mostly my baby). FreeBSD might work very very well, but it does have some limitations. The goal (for me) is for the new VM code to be appropriate for the new G2 kernel, and also applicable for other applications (perhaps.) John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901150545.AAA19169>