pcg@cs.aber.ac.uk (Piercarlo Grandi) (01/21/91)
On 19 Jan 91 13:39:14 GMT, mo@messy.bellcore.com (Michael O'Dell) said: mo> Various people have posted here recently expounding on the clear and mo> obvious (to them) botches of the original SunMMU design. One thing mo> to keep in mind is that Sun was shipping systems with virtual memory mo> LONG, LONG before the 68881 was little more than a "gee I wish I mo> had" dream. The 68451 was not that long coming, and could be used as a TLB. Yes, it was slow. As to the issue of whether it is better to add a wait state or to make the entire system thrash in the pager, it all depends on whether you sell to people that believe benchmarks run on machines with infinite central memory or on whether your customers want real system performance under load. Sun made the correct marketing move, I surmise :-(. mo> Because the mmu had to be done in random logic (asics and such mo> weren't there then), [ ... ] Yes, this is well known. There are two observations: 1) A lot of other manufacturers had the same problems. Nobody botched it quite as badly as Sun. 2) Sun persisted in the same type of design well past where it had made sense, if ever. It is like, let me repeat, the madness of System V doing expansion swaps ten years after V7 on a PDP-11. mo> THe question of when is it defensible to take the time to redo the mo> MMU (again) is another matter. Not to mention that they botched the first SPARC MMU as well. mo> All the new SPARC chipset machines have more a classic page-table in mo> memory, hardware-reloaded TLB MMU/cache controller chips. (This is mo> the "reference MMU", I haven't yet heard of a Sun product with the "reference MMU". There is malicious and obviously unfounded speculation that this is so cloners will not be able to run a binary of SunOS identical to Sun's. From the BYTE account of a couple of SPARC clones, neither used the reference MMU, to be more compatible with the SparcStation. mo> and it has a 4k pagesize, basically.) Incidentally, even a 4KB pagesize is still too large, even if it is barely tolerable. 8KB was simply crazy, for a workstation/time sharing server. Surely in due time even Sun will put out a machine with the reference MMU; as of now they'd rather sell you for a pretty steep price a patch to SunOS that corrects some of the worst software problems that accompany the design mistakes of the current SPARC MMU. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
paul@taniwha.UUCP (Paul Campbell) (01/22/91)
In article <PCG.91Jan20191955@teacho.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >The 68451 was not that long coming, and could be used as a TLB. Yes, it >was slow. As to the issue of whether it is better to add a wait state or >to make the entire system thrash in the pager, it all depends on whether well actually usually 3-5 wait states :-). Most of the '451 based systems and most of the early systems that were based on clones of the SUN MMU were swapping systems - and of course swap based systems perform BETTER than VM systems - but marketting people don't want to hear that (no page fault overhead while running - but you can't run something bigger than real memory). >1) A lot of other manufacturers had the same problems. Nobody botched it >quite as badly as Sun. I have to disagree - around that time I found myself porting Unix to a whole host of '451 and SUN clones - lot's of people screwed up in their MMU design (some to the point where the kernel wasn't even protected from user mode) - I wont mention any names (to protect the guilty). >Incidentally, even a 4KB pagesize is still too large, even if it is >barely tolerable. 8KB was simply crazy, for a workstation/time sharing >server. Another issue that hasn't really been talked about here has to do with disk bandwidth, esp. on some of the slower transfer-rate disks (that can't do 1:1 interleaved transfers). With 8k pages you have to move 8k/page fault so latency from disk can be much higher. These days it's not such a big deal since most disks can do 1:1 but even a couple of years ago a system configured with 'big' ie 8k pages could perform much worse than a 4k or 2k system it also reduces the granularity of the in-core page cache but increases the efficiency of the TLB. These are hard trade-offs to make since their effects (TLB misses vs page-faults vs disk transfer rates) range across a whole range of scales and tend not to be measured together to give a single number you can measure them with Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P Where do you find a "kinder gentler nation" when you need one these days?
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (01/22/91)
In article <756@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes: | Another issue that hasn't really been talked about here has to do with disk | bandwidth, esp. on some of the slower transfer-rate disks (that can't do | 1:1 interleaved transfers). With 8k pages you have to move 8k/page fault | so latency from disk can be much higher. These days it's not such a big | deal since most disks can do 1:1 but even a couple of years ago a system | configured with 'big' ie 8k pages could perform much worse than a 4k or | 2k system I think it's a fair statement that the optimal page size is a function of disk access time, throughput, and physical memory size. In a system with small memory a small page size may result in better memory usage, within limits. Obviously subject to CPU and MMU capability considerations as well. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "I'll come home in one of two ways, the big parade or in a body bag. I prefer the former but I'll take the latter" -Sgt Marco Rodrigez
gsarff@meph.UUCP (Gary Sarff) (01/25/91)
In article <1991Jan19.133914.23871@bellcore.bellcore.com>, mo@messy.bellcore.com (Michael O'Dell) writes: >Various people have posted here recently expounding on the >clear and obvious (to them) botches of the original SunMMU design. >One thing to keep in mind is that Sun was shipping systems with >virtual memory LONG, LONG before the 68881 was little more than ^^^^^ actually 68851 This is not a flame, we all knew what you meant. 8-) >a "gee I wish I had" dream. Because the mmu had to be done in random >logic (asics and such weren't there then), it had to be simple, >and if it weren't to introduce wait states, it had to be fast. >The way to do that at the time was to use fast static RAMs and >implement the direct lookup algorithm in hardware. When originally done, Someone out there in netland may remember WICAT also, 68K based systems multiuser multitasking OS, protected address spaces, MMU made with fast static ram, some gates, some pals, voila, hardware memory management, 4K pages, because of the size of the static ram used. --------------------------------------------------------------------------- I _don't_ live for the Leap! ..uplherc!wicat!sarek!gsarff