re:
http://www.garlic.com/~lynn/2012c.html#34 nested LRU schemes
the default 3880-11 page/record cache scenario was 3081 with 32mbytes of
real storage and 3880-11 controller with 8mbytes of cache. Every record
read through controller cache would initially be in both the cache and
3081 memory. A page that wasn't in the 3081 memory wouldn't be likely to
also be in the 3880-11 cache ... unless the number of pages in 3880-11
memory/cache was significantly larger than the number of pages in 3081
memory. This is a variation on nested caches & related to nested LRU. I
had earlier developed strategy that I called dup/no-dup ("dup" for
duplicate) to address a similar situation with 2305 fixed-head paging
drums. For constrained/contention for paging device ... either maintain
page on disk or in memory (but not both, aka no-duplicate). In the 2305
case, I would de-allocate space on 2305 when page was read to memory
... this incurred the requirement that when page was selected for
replacement, it would always have to be written ... even if it hadn't
been changed ... a similar strategy was later used for "big-pages" (but
for other reasons):
http://www.garlic.com/~lynn/2012c.html#28 5 Byte Device Addresses
So for the 3880-11, it was possible to do a "destructive" read ... it it
wasn't already in cache, the read from disk would be "cache-bypass"
read, while if it was in cache, it would deallocate the cache location
after the read. Then the only pages that would be in the 3880-11 cache
were pages that were written when be selected for replacement in memory
(and since reads didn't take up space in the cache, these pages would
have longer cache lifetime and some chance they would still be in the
cache if it was needed in the future). some past discussion of
dup/no-dup
http://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
http://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
http://www.garlic.com/~lynn/2002f.html#20 Blade architectures
http://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer
cylinders still faster than inner cylinders?
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2007c.html#0 old discussion of disk controller
chache
http://www.garlic.com/~lynn/2007l.html#61 John W. Backus, 82, Fortran
developer, dies
http://www.garlic.com/~lynn/2008f.html#19
Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2008k.html#80 How to calculate effective page fault
service time?
http://www.garlic.com/~lynn/2010i.html#20 How to analyze a volume's access by
dataset
http://www.garlic.com/~lynn/2011.html#68 Speed of Old Hard Disks
http://www.garlic.com/~lynn/2011.html#70 Speed of Old Hard Disks
more drift to global/local and global/partitioned argument (as opposed
to nested) ... past global LRU email
http://www.garlic.com/~lynn/lhwemail.html#globallru
are this past posts mentioning "DMKCOL"
http://www.garlic.com/~lynn/2006y.html#35 The Future of CPUs: What's After
Multi-Core?
http://www.garlic.com/~lynn/2007.html#3 The Future of CPUs: What's After
Multi-Core?
http://www.garlic.com/~lynn/2010i.html#18 How to analyze a volume's access by
dataset
http://www.garlic.com/~lynn/2011.html#70 Speed of Old Hard Disks
http://www.garlic.com/~lynn/2011.html#71 Speed of Old Hard Disks
In the late 70s, we did high-performance, light-weight trace for every
record access by system ... either the native vm370 system as well as
any guest operating system. This was used with sophistcated i/o cache
simulator ... able to simulate arbitrary sized caches that were
positioned at the system level, split at the channel level, at the
controller level, and/or at the device level (some number of other
variations).
One of the findings was that for given amount of electronic storage,
the most thruput was from system level global cache ... supporting
the argument that global LRU outperformed a partitioned local
LRU ... previously mentioned in this reference
http://www.garlic.com/~lynn/2012c.html#17 5 Byte Device Address
and
http://www.garlic.com/~lynn/2006w.html#46
The caveat was pathelogical behavior that polluted cache with non-reused
information ... like large sequential read. Partitioned caches would
isolate sequential read to specific cache and not also destroy all the
entries in other caches. Another scenario is to recognize behavior like
sequential read and treat those records differently.
The example from the 3880-13 full-track "cache" ... and the 90% "hit
rate" for sequential read ... the same level of throughput would be
achieved by a hardware track buffer (much less electronic storage
needed) ... and/or software full-track buffering.
Part of the scenario across the ages ... with regarding to global
system-level cache being the most efficient ... from cache hit rate
stand-point ... would be things like hardware limitations on maximum
amount of attached electronic storage ... or software that didn't
scale well for larger amounts of storage.
The hardware limitation scenario shows up in the 3090 expanded storage
... even tho both standard processor memory and expanded storage used
essentially the same memory technology. Later mainframe generations
had all memory technology used the access ... but LPAR configuration
provided option of simulated 3090 expanded storage using standard
memory ... because of various software limitations.
misc. past posts discussing 3090 expanded storage continued
to live as LPAR configuration simulation option:
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006l.html#43 One or two CPUs - the pros & cons
http://www.garlic.com/~lynn/2008.html#49 IBM LCS
http://www.garlic.com/~lynn/2009d.html#29 Thanks for the SEL32 Reminder, Al!
http://www.garlic.com/~lynn/2010n.html#39 Central vs. expanded storage
http://www.garlic.com/~lynn/2011f.html#69 how to get a command result without
writing it to a file
--
virtualization experience starting Jan1968, online at home since Mar1970
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
