[EMAIL PROTECTED] writes: > Then a subset of those categories would have to be code > and data, with the rare exception where code is data > (writable code segment which god never meant happen). > > I suppose there would also have to be special handling > of data pages that were suddenly changed to code. > > Comments on the discussion: > > 1. An OS did not need VM to do relocation. Example: KA10. > 2. Do not confuse paging hardware with virtual memory. > They are different. The reason this confusion happens > is because both were usually done during the same > major version OS release. If your new CPU has paging > hardware, you might as well schedule your VM project > at the same time. You might as well subject the customer > to both pains all at the same time. It was like > pulling a tooth: yank it and get it over with or tweak > it and have years of long drawn annoying pain in the > nethers.
i've described two instances where there was special case processing ... and both instances resulted in non-optimal implementations ... * one was the initial morph from cp67 to vm370 where they had actual lists of pages for the scanning/reset/replacement selection and "shared" pages were treated specially ... not based on reference bits * the other was the initial morph from mvt to os/vs2 where they would bias the replacement selection for non-changed pages before changed pages post including description of the above two scenarios http://www.garlic.com/~lynn/2006i.html#43 virtual memory i had arguments with both groups over the details and they went ahead and did it anyway (which, in both cases, got corrected much later ... the os/vs2 they had to do the correction themselves, the vm370 shared pages, i was able to correct in the release of the resource manager). i had also done a paging, non-virtual memory thing originally as an undergraduate in the 60s for cp67 ... but it was never picked up in the product until the morph of cp67 to vm370 where it was used. the issue was the kernel code ran real mode, w/o hardware translate turned on. all its addressing was based on real addresses. when dealing with addresses from virtual address space ... it used the LRA (load real address) instruction that translated from virtual to real. the issue was that the real kernel size was continuing to grow as more and more features were being added. this was starting to impact the number of pages left over for virtual address paging. recent post in this thread making mention of measure of "pageable pages" (after fixed kernel requirements): http://www.garlic.com/~lynn/2006i.html#36 virtual memory http://www.garlic.com/~lynn/2006j.html#2 virtual memory so i created a dummy set of tables for the "kernel" address space ... and partitioned some low-useage kernel routines (various kinds of commands, etc) into real, 4k "chunks". I positioned all these real chunks at the high end of the kernel. When there were calls to addresses above the "pageable" line ... the call processing ... instead of directly transfering would run the address thru the dummy table to see if the chunk was actually resident. if it was resident, then the call would be made to the translated address location ... running w/o virtual memory turned on. if the 4k chunk was indicated as not resident, the paging routine was called to bring it into storage before transferring to the "real" address. during the call, the page fixing and lock ... that CCWTRANS for performing virtual i/o ... was used for preventing the page for be selected from removal from real storage. the count was decremented at the return. otherwise these "pageable" kernel pages could be selected for replacement just like any other page. some recent mentions of CCWTRANS http://www.garlic.com/~lynn/2006.html#31 Is VIO mandatory? http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory? http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT http://www.garlic.com/~lynn/2006i.html#33 virtual memory this feature never shipped as part of the cp67 kernel, but was picked up as part of the initial morph of cp67 to vm370. Later for the resource manager, i also created a (2nd) small dummy set of tables for every virtual address space that was used for administrative writing of tables to disk. tables were collected into page-aligned 4k real chunks and the page I/O infrastructure was used for moving the tables to/from disk (in a manner similar to how i had done the original pageable kernel implementation) previous description of "paging" SWAPTABLEs. http://www.garlic.com/~lynn/2006i.html#24 Virtual memory implementation in S/370 in the initial morph of cp67->vm370, some of cms was re-orged to take advantage of the 370 shared segment protection. however, before 370 virtual memory was announced and shipped, the feature was dropped from the product line (because the engineers doing the hardwareretrofit of virtual memory to 370/165 said that shared segment protect and a couple other features would cause an extra six month delay). a few past posts mentioning virtual memory retrofit to 370/165: http://www.garlic.com/~lynn/2006i.html#4 Mainframe vs. xSeries http://www.garlic.com/~lynn/2006i.html#9 Hadware Support for Protection Bits: what does it really mean? http://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370 as a result, the shared page protection had to redone as a hack to utilize the storage protect keys that had been carried over from 360. this required behind the scenes fiddling of the virtual machine architecture ... which prevented running cms with the virtual machine assist microcode activated (hardware directly implemented virtual machine execution of privilege instructions). later, in order to run cms virtual machines with the VMA microcode assist, protection was turned off. instead a scan of all shared pages was substituted that occured on every task switch. an application running in virtual address space could modify shared pages ... but the effect would be caught and discarded before task switch occured (so any modification wouldn't be apparent in other address spaces). this sort of worked running single processor configurations ... but got much worse in multi-processor configurations. now you had to have a unique set of shared pages specific to each real processor. past post mentioning the changed protection hack for cms http://www.garlic.com/~lynn/2006i.html#9 Hadware Support for Protection Bits: what does it really mean? http://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370 past posts mention pageable kernel work: http://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...] http://www.garlic.com/~lynn/2001l.html#32 mainframe question http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan http://www.garlic.com/~lynn/2002n.html#71 bps loader, was PLX http://www.garlic.com/~lynn/2002p.html#56 cost of crossing kernel/user boundary http://www.garlic.com/~lynn/2002p.html#64 cost of crossing kernel/user boundary http://www.garlic.com/~lynn/2003f.html#12 Alpha performance, why? http://www.garlic.com/~lynn/2003f.html#14 Alpha performance, why? http://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why? http://www.garlic.com/~lynn/2003f.html#23 Alpha performance, why? http://www.garlic.com/~lynn/2003f.html#26 Alpha performance, why? http://www.garlic.com/~lynn/2003f.html#30 Alpha performance, why? http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story http://www.garlic.com/~lynn/2004b.html#26 determining memory size http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants] http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors http://www.garlic.com/~lynn/2005f.html#16 Where should the type information be: in tags and descriptors http://www.garlic.com/~lynn/2006.html#35 Charging Time http://www.garlic.com/~lynn/2006.html#40 All Good Things -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
