[EMAIL PROTECTED] (Ted MacNEIL) writes: > That's why there can be a 'double paging' penalty for a LINUX (or > z/OS, or z/VM, or...). > > z/VM, and its predecessors, has always had the capability to defines > more storage than is on the box. > > It even has swap files.
i had other problems with the os/vs2 group (initially svs before it morphed into mvs). one was all the stuff about LRU replacement algorithms and what it met. lots of posts on the subject http://www.garlic.com/~lynn/subtopic.html#wsclock early on, the pok performance modeling group had discovered on a page fault that if it selected "non-changed" pages (for replacement) before "changed" pages ... there wouldn't need the overhead of doing a write before the read. i tried to convince them it would be violated fundamental tenents of LRU replacement paradigm. It wasn't until well into MVS releases that somebody pointed out that they were selecting for replacement, high-use, non-changed, system/shared executable pages, before (lower use) private application data pages (which were changed/modified). another issue isn't just the double paging overhead ... there is the possibility that a virtual guest is running a LRU-like replacement algorithm and selecting a real page with a low use virtual page for replacement (to be refreshed with the missing page). VM may also be doing LRU-like replacement algorithm and noticed (also) that the guest's real page (virtual machine virtual page) hadn't been recently used and selected it for replacement. The pathelogical problem is that the guest may always be deciding it needs one of its real pages (because the corresponding virtual pages weren't being used) moments after VM has decided to remove the corresponding guest virtual machine page from real storage .... aka running a virtual guest's LRU-like replacement algorithm can violate the premise behind LRU replacement ... since the guest's real page that corresponds to the guest's least recently used virtual page has some probability of being the next page that the guest might actually decide to use misc. past posts in thread: http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#62 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#64 CSA 'above the bar' ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
