[EMAIL PROTECTED] (Ted MacNEIL) writes:
Also, sub-systems like DB2 are getting to the point where you
should/could/would not like it to page. Sort of throws the concept
out the window, doesn't it?
previous post in thread
http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation
one of the things that can happen is if you run a subsystem doing
LRU-like activity management in a virtual address space that is
also being managed with a LRU-like activity management.
I first noticed this in the 70s ... when some of the os/360 migrated to
virtual storage support and were in turn run in a virtual machine.
vm370 was managing the virtual address space (of the virtual machine)
with an LRU-like algorithm .... while the guest operating system
was also managing (what it thot to be real storage) with a
LRU-like algorithm.
if the virtual quest took a page fault ... it would examine its
available storage for the least-recently used page to "replace". if the
vm370 hypervisor was also paging ... it will also have used the same
criteria to remove the least-recently used page from real storage
... however, this would possibly also going to be the most likely next
page that the virtual guest was going to start using (when it did its
own paging).
dbms subsystems tends to have large buffer storage ... that are managed
in a manner analogous to virtual storage ... i.e. the least recently
used buffer is likely to be replaced with the latest requested record.
A heavily used dbms subsystem is likely going to use the maximum storage
available to it (because it is going to replace its least recently used
buffers with the most recently requested records).
one of my statements from the 70s was that running an LRU-like algorithm
under a LRU-like algorithm can result in very pathelogical behavior and
the virtualized quest/subystem can exhibit exact opposite of behavior of
assumptions that are the foundation of LRU implementations (the least
recently used page is the least likely to be needed in the near future,
a "virtual" LRU-like algorithm is most likely to use the least recently
used page).
lots of past posts mentioning virtual storage page replacement and/or
page/buffer replacement algorithms
http://www.garlic.com/~lynn/subtopic.html#clock
misc. past posts mentioning original rdbms & sql implementation
(originally all done on vm370 platform)
http://www.garlic.com/~lynn/subtopic.html#systemr
including tech. transfer from bldg. 28 to endicott for sql/ds.
for other topic drift one of the people in the meeting mentioned in the
following post claimed to have handled large part of the technology
transfer from endicott to bldg. 90 for DB2
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15
above meeting was related to turning out ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp
and other old email related to working on ha/cmp scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa
another scenaro of running subsystem in a paged virtual address
space ... which believed that the virtual address space was really
memory was when the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
originally did the port of apl\360 to cms for cms\apl. The problem
was that apl\360 believed its "workspace" was resident real storage
and had a storage allocation strategy that would assign a new storage
location for every assignment statement ... until it had exhausted
the available (workspace) available storage ... at which point
it would do garbage collection and collapse all allocated locations
into contiguous memory ... and then starting all over again. It
wasn't too bad to repeatedly use all of a (real storage) 16kbyte
swapped workspace. However, in cms virtual address space environment,
the available workspace could easily be several mbytes (or even
nearly all of 16mbytes). this would be under cp67 on a 360/67
with typically 512kbytes to 1mbyte of real storage. very quickly it was realized
that the apl\360 storage management and garbage collection implementation
had to be significantly reworked to move it to a virtual memory
environment.
Turns out one of the early major uses of cms\apl on the cambridge
cp67 machine was the business planning people in armonk. prior to
cms\apl, apl\360 with only 16kbyte-32kbyte workspace sizes didn't
provide much room for working on any real world problems. significantly
opening up the apl workspace size with cms\apl allowed for work
on some real world problems. the business planning people loaded
the most sensitive corporate information ... detailed customer
information ... on the cambridge machine and ran sophisticated
business modeling applications implemented in apl.
for other drift, this represented some interested security
issues ... since the cambridge system was also being used
by numerous students and others from colleges and universities
in the cambridge area. recent post on that particular topic
drift:
http://www.garlic.com/~lynn/2007o.html#36 It's No Secret: VMware to Develop
Secure Systems for NSA
http://www.garlic.com/~lynn/2007o.html#38 It's No Secret: VMware to Develop
Secure Systems for NSA
http://www.garlic.com/~lynn/2007o.html#39 It's No Secret: VMware to Develop
Secure Systems for NSA
----------------------------------------------------------------------
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
