This message was forwarded to you from Deja News by hjl@lucon.org.
Deja News, the discussion network, offers free web-based access to more than
50,000 high-quality discussion forums. Come and visit us on the web at
http://www.dejanews.com/=zzz_maf/
------------------------------------------------------------------------------
Join and get 4 bestselling audiobooks 1c
http://www.audiobookclub.com/micro/home.asp?AID=S036L004B009
------------------------------------------------------------------------------
(beginning of original message)
Subject: Re: Review and report of linux kernel VM
From: "John S. Dyson" <dyson@dyson.iquest.net>
Date: 1999/01/15
Newsgroups: mpc.lists.freebsd.hackers,muc.lists.freebsd.hackers
>
> 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
(end of original message)
------------------------------------------------------------------------------
You can view this message and the related discussion by following this link:
http://www.dejanews.com/=zzz_maf/dnquery.xp?search=thread&svcclass=dnserver&recnum=%3c199901150545.AAA19169@dyson.iquest.net%3e%231/1
We hope to see you soon at Deja News, the discussion network.
http://www.dejanews.com/=zzz_maf/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/