lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) (02/11/90)
In article <76700129@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >The Pilot OS designers copied the Multics file mapping trick, >and later lived to regret it. The kernel code eventually ate up about >11,000 lines, and the applications programmers never recouped this >huge kernel investment. Then perhaps the correct answer is Mach's "external pager" feature. An application can have its own page fault handler, thus punting the code out of the kernel. I also don't see how the kernel designer could predict the needed functionality: what if the application wanted to constrain the ordering of the paging actions? I vote for 64 bit addresses. Two reasons: One: ensemble machines. NCUBE claims they can extend their latest machine to 8K processors (with all-PCB interconnect: no flat cables). Ideally, you would like every node to have addresses big enough to access the entire ensemble's physical memory. Since their standard (ie smallest) node has 1MB, that means 33 bits just as starters. Two: flat access to disk. A database manager or file system checker would like to be able to map at least one disk into memory. The reason is that the these programs keep track of a lot of buffered data, and have to keep a map of what they put where. Meanwhile, the underlying virtual memory is running its own mapping. Even worse, noncontiguous file systems (e.g. Unix) are running a complicated mapping of file pages to disk pages. The Mach pager suggests the idea of a database system that uses a single mapping - virtual memory - to replace three mutually ignorant levels of mapping. Right now, a single rack of 5" disks holds about 20 gigabytes. I rest my case. -- Don D.C.Lindsay Carnegie Mellon Computer Science