In the 1980s, I recall shipping a bunch of systems based on PDP-11/23's and /53's, the occasional 11/44 or /73. A Q-bus -11 with 512KB and an ST-506 interfaced disk running RSX11M-PLUS was pretty responsive. You could easily put 1/2 dozen or more people on it and none of them would complain that it was too slow, because loading a new program (task image) selected from a menu happened pretty fast. Small VAXen or UNIX boxes needed a lot more hardware capability to get anywhere close to that level of responsiveness. How come?
One thing that the RSX11 family did (and RT-11, too), is that task images, both in memory and as files, are generally contiguous (shared libraries, shared regions, and supervisor mode libraries didn't change the overall picture much). So when you are ready to load a task into memory you first allocate a contiguous block of RAM, then you find the file on disk and tell the disk driver to DMA it right into place, hook up the TCB and task header, and go. No scatter/gather I/O. No faulting the image into memory. So the process of starting a new task is way faster than on VMS or UNIX or Windows. I don't know enough about how TOPS-10 did things to compare that system, but that seemed pretty responsive, too. Of course, there were costs to doing this, too (remember the SHUFFLER that ran when RSX11 couldn't find enough contiguous RAM: it moved task images and so on around trying to make big enough holes to fit in more tasks. And you had to swap complete tasks out rather than just memory pages that weren't getting used).
I was thinking about how responsive a general-purpose system you could build based on current PC hardware and this kind of memory/filesystem architecture. Certainly, you could build a file system with contiguous files, but it would need the kind of maintenance that ODS-1 filesystems needed (frequent defragmentation, etc.). But would you really want to implement a memory management scheme that managed contiguous blocks of RAM, then updated page tables to make the thing go? With 64K or so task images this is not so bad, but the system I am on right now says my firefox browser process has 290MB resident, out of a total image of 733MB. You could easily build a system that just grabbed pages from a free list as needed, and did not allow page faulting to occur (i.e. all pages are resident), but this seems to me that it would lose the benefit of fast image loading because you need to load all those scattered pages before a task can be started. I guess if the allocated pages were big enough this wouldn't hurt too much (64K?), but wasted RAM is still an issue (isn't it)?
Certainly, embedded systems with tiny to medium filesystems can be quite responsive (everything important is resident in memory), but can you scale up the kind of historical O/S memory/filesystem architecture I am talking about to general purpose computing with the kind of programs we now have? Or has that ship sailed forever? Has the cost of hardware dropped to the point that it just doesn't matter much anymore? What do you think?
One thing that the RSX11 family did (and RT-11, too), is that task images, both in memory and as files, are generally contiguous (shared libraries, shared regions, and supervisor mode libraries didn't change the overall picture much). So when you are ready to load a task into memory you first allocate a contiguous block of RAM, then you find the file on disk and tell the disk driver to DMA it right into place, hook up the TCB and task header, and go. No scatter/gather I/O. No faulting the image into memory. So the process of starting a new task is way faster than on VMS or UNIX or Windows. I don't know enough about how TOPS-10 did things to compare that system, but that seemed pretty responsive, too. Of course, there were costs to doing this, too (remember the SHUFFLER that ran when RSX11 couldn't find enough contiguous RAM: it moved task images and so on around trying to make big enough holes to fit in more tasks. And you had to swap complete tasks out rather than just memory pages that weren't getting used).
I was thinking about how responsive a general-purpose system you could build based on current PC hardware and this kind of memory/filesystem architecture. Certainly, you could build a file system with contiguous files, but it would need the kind of maintenance that ODS-1 filesystems needed (frequent defragmentation, etc.). But would you really want to implement a memory management scheme that managed contiguous blocks of RAM, then updated page tables to make the thing go? With 64K or so task images this is not so bad, but the system I am on right now says my firefox browser process has 290MB resident, out of a total image of 733MB. You could easily build a system that just grabbed pages from a free list as needed, and did not allow page faulting to occur (i.e. all pages are resident), but this seems to me that it would lose the benefit of fast image loading because you need to load all those scattered pages before a task can be started. I guess if the allocated pages were big enough this wouldn't hurt too much (64K?), but wasted RAM is still an issue (isn't it)?
Certainly, embedded systems with tiny to medium filesystems can be quite responsive (everything important is resident in memory), but can you scale up the kind of historical O/S memory/filesystem architecture I am talking about to general purpose computing with the kind of programs we now have? Or has that ship sailed forever? Has the cost of hardware dropped to the point that it just doesn't matter much anymore? What do you think?
