zrm@mit-eddie.UUCP (Zigurd R. Mednieks) (07/19/83)
The LMC at Usenix has the HCR Unity system on it and did not, as far as I could tell, page. This is, in a word, silly. National's port pages and works quite well when loaded ( I started 6 nroffs in the background to be sure that the system was loaded and all three people using it at the time still got interactive response. Further, since the hard part of adapting 4.1 has been done by the chip manufacturer, and done well, we will hopefully see most vendors using the same port. Why not LMC? I was puzzled that "ps" did not report a kernal process for paging, ala "swapper". The speaker from national gave the impression that paging was done quite differntly on their 16000 port. Just how differnt is it? Cheers, Zig
lneff@nsc.UUCP (07/21/83)
GENIX -- National Semiconductor's port of 4.1 to NS16032-based hardware -- does not have a separate paging daemon process. Because the hardware architecture supplies and maintains a reference bit in our page table entries, our page replacement algorithm is simpler than the one on the VAX. It is called by the kernel's page allocation routine when physical memory runs out. We keep a pointer into physical memory and examine pages starting with that pointer. We find the page table entry that maps the page and check its reference bit. If it's off, then we stop and pick this page to page out. Otherwise we turn off the reference bit and go on to the next page. If the page isn't referenced by the time we cycle through memory, then we know it isn't in active use and we pick it the next time around. This is a simplified explanation -- there are other factors involved in picking a page to remove from memory, but the reference bit is the most important. Once a page has been chosen, the disk I/O is started and the kernel reschedules. When the I/O is completed, the disk interrupt routine does some cleanup and wakes up the process that needed the memory. Freed but dirty pages are zeroed in the kernel's idle loop. When the paging rate is high or free memory has been low for several seconds, then the schedular/swapping process frees a number of pages at once by swapping out an unused shared text or a process. The schedular and swapping algorithms are similar to the 4.1 code, except we always try to swap unused shared texts before we swap processes, and we made changes to allow a process to be "partially swapped" if the memory situation warrants it. To "swap" a GENIX process, we step through the process's level 2 page tables and page out every memory page. Then we step through the level 1 page table and page out every level 2 page table. Laura Neff National Semiconductor Corporation !menlo70!nsc!lneff GENIX is a trademark of National Semiconductor Corporation.
tracy@hcr.UUCP (Tracy Tims) (07/22/83)
Well, Zig, you are wrong. The LMC box shown at Usenix does page. It was even paging at Usenix. It has paged since the kernel was first running. Tracy Tims (hcr!hcrvax!tracy)
thomson@utcsrgv.UUCP (Brian Thomson) (07/25/83)
But ... isn't a paging process still a good idea? It's good to have
something laundering idle dirty pages, particularly if (like the 4.1
pager) it can adjust its work rate depending on how low the memory
supply is. Graceful degradation and all that ...
--
Brian Thomson, CSRG Univ. of Toronto
{linus,ihnp4,uw-beaver,floyd,utzoo}!utcsrgv!thomsonwagner@utcsstat.UUCP (07/26/83)
Background paging processes are an obvious win only when they only consume "otherwise idle" resources. Most small-config unix systems dont have dedicated paging devices, and the disk may very well have better things to do than run around cleaning up pages just in time to have them get them dirty again. Its really a much more complicated trade-off than it is normally made out to be. Most people seem to subscribe to this sort of stuff on a religious basis rather than a scientific one. Michael Wagner, UTCS (utzoo!utcsstat!wagner)
thomson@utcsrgv.UUCP (Brian Thomson) (07/27/83)
Whoa. 'Religious basis?' Puh-leeze.
I am in favour of solving paging by avoiding it. Our 780 has
8 megabytes and never pages. I like that just fine.
But if you're going to build a paging system, build it so
Using the kernel's idle loop to zero freed but dirty pages is,
I think, and if I understand it correctly, a bad idea. It strongly
couples page cleaning to the availability of idle cpu cycles. If
you don't want that dependency, tough. You're stuck with it.
So, that's my religious philosophy. Build your systems so YOU
control their behaviour. How can that be wrong?
The business of 'cleaning up pages just in time to have them
get them[sic] dirty again' is, of course, a red herring. You
can also pre-empt clean pages just in time to have them fault
back in. That's what strategies are for.
This Sermon brought to you from the Mount of ...
--
Brian Thomson, CSRG Univ. of Toronto
{linus,ihnp4,uw-beaver,floyd,utzoo}!utcsrgv!thomsonzrm@mit-eddie.UUCP (Zigurd R. Mednieks) (07/30/83)
I stand corrected, but my information came from someone in the HCR booth. Cheers, Zig