> 4/490 is sun4 architecture and at the moment only the 4/300
> series works. If the sun3 people merge in their VME SCSI stuff
> then all that is needed is to support the worlds worst mmu.
Don't be silly- "world's cheapest" is a better term- where else can
you do an MMU and virtual address indexed cache for a couple of
SRAMs and comparators?
For one, I also vote it as one of the worst mmu/cache combinations to
program in the world. Most of the pains are due to the fact that it
does not have at least one of the following:
1) Some 1 to 1 mapped area of virtual address space (ala MIPS, Alpha)
or
2) Decent software TLB miss handling via LRU replacement in CAM
(ala UltraSparc, PPC)
or
3) Hardware page table walk (ala ix86, Sparc/SRMMU)
Without one of the above three, getting decent performance is a 3 ring
circus act under Linux. It requires software to keep too much state
and work too hard. (Having had to write support for all 3, my
personal preference is #2, it gives maximum flexibility of
implementation to the software)
I believe for sun4/sun4c the easiest to implement would have been
#1 above, you have a single comparator in the front end of the
address logic, and if the top bit is set you let the rest of the bits
drop straight in as the physical address if no VAC hit is detected and
thus you need to go to main memory.
So it may be cheap, nice, and a simple design, but often hardware
level simplicity can translate into massive software level complexity.
But there are other cases where hardware level simplicity translates
into simple software support too. The difference is when the hardware
and software people are allowed to get into the same room together.
I at least do not feel guilty in branding various Sparc mmu/cache
implementations one way or another, simply because I have done the
software support for the large majority of them.
Later,
David S. Miller
davem@redhat.com
-
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/