Mark Bodenstein wrote:
Thanks to everyone that replied. We'll look into using additional
storage for CICS and VSAM buffers, and possibly for DFSORT. We don't
run any Java at this point. We may also add some additional XSTORE to
z/VM.
this somewhat descends into the area of system being able to more dynamically
adapt
to different requirements with global infrastructure and basic assumptions
related
to "LRU" (least recently used) replacement algorithms related to managing
caches, paging, buffers, etc).
LRU replacements algorithms basically tend to assume that storage used in the
recent
past will assumed to be used in the near future (and therefor replace storage
that
has been least recently used). This is supported by studies that have observed
program
behavior with respect to "recently" used storage. The issue is that its
usefulness for
predicting future storage use patterns can significantly degrade as the history interval
becomes too large (i.e. no longer represents "recent" behavior). A lot of reference use
algorithms tends to approximate LRU by resetting a storage reference bit ... on
a frequency
that is proportional to both the amount of storage and the demand for storage (if the
reset frequency drops below some threshold, the information can become useless).
so various issues to go to static partition allocation offsetting the benefits
of
optimized global dynamic allocation
1) resource management doesn't know how to deal with global storage
infrastructure
with lots of different kinds of competing demands
2) different competing uses may benefit from application specific policies for
replacement
3) partitioning storage is more likely to increase the frequency of various
reference
use reset intervals ... improving the quality of the subsequent replacement
decisions.
With respect to #3, one of the characteristics of "two-handed" clock
replacement algorithm
was to not make resetting of reference information exactly synchronous with the
testing
of the reference information. the "hand" doing the reference reset was offset from the
"hand" doing the reference testing. The degree of offset would be adjusted to compensate
for "large" storage sizes that resulted in the reset frequency dropping below
useful threshold.
I had implemented global LRU clock-like replacement algorithms as undergraduate
in the 60s ... lots
of posts mentioning replacement algorithms
http://www.garlic.com/~lynn/subtopic.html#wsclock
Also, various old email mentioning global LRU and replacement algorithms
http://www.garlic.com/~lynn/lhwemail.html#globallru
In the early 80s, there was some issues raised with somebody working on global
LRU replacement
algorithms for Stanford PHD ... and I was asked to provide supporting detail
from my work
when I was an undergraduate in the 60s ... old communication on the subject
http://www.garlic.com/~lynn/2006w.html#email821019
in this post
http://www.garlic.com/~lynn/2006w.html#40 The Future of CPUs: What's After
Multi-Core?
previous posts touching on the subject that a well-implemented dynamic adaptive
resource
management should be able to outperform a partitioned operation ... in
discussion/threads
mentioning whether it is better to partition between XSTORE and normal storage
... or
have everything as single, unpartitioned storage.
http://www.garlic.com/~lynn/95.html#15 multilevel store
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2001m.html#53 TSS/360
http://www.garlic.com/~lynn/2002c.html#53 VAX, M68K complex instructions (was
Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002e.html#26 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003p.html#41 comp.arch classic: the 10-bit byte
http://www.garlic.com/~lynn/2003p.html#46 comp.arch classic: the 10-bit byte
http://www.garlic.com/~lynn/2005.html#17 Amusing acronym
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005j.html#13 Performance and Capacity Planning
http://www.garlic.com/~lynn/2006.html#16 Would multi-core replace SMPs?
http://www.garlic.com/~lynn/2006l.html#43 One or two CPUs - the pros & cons
http://www.garlic.com/~lynn/2006r.html#35 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#16 memory, 360 lcs, 3090 extended store,
etc
http://www.garlic.com/~lynn/2006s.html#17 bandwidth of a swallow (was: Real
core)
http://www.garlic.com/~lynn/2007c.html#23 How many 36-bit Unix ports in the old
days?
----------------------------------------------------------------------
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
