On 11/26/2014 11:19 AM, Bob Shannon wrote:
<snippage>
I tend to agree with the OP. LLA will only check VLF for modules it previously
cached. Granted there may be some trimming, but I don't ever recall seeing less
than a 100% hit ratio for LLA. The other VLF exploiters behave differently and
the SMF statistics for them tend to be helpful. The CSVLLIX1 exit is required
for accurate LLA fetch statistics.
Bob Shannon
Rocket Software
<SNIPPAGE>
Wouldn't the LLA hit rate be based on it having the directory
information as opposed to having to go read it (something about
FREEZE vs. NOFREEZE ?)?
Then, wouldn't the VLF data be based on an attempt to fetch, when
it doesn't have it, so that you have a "cache" miss?
After all, VLF does not start doing caching until there has been
a module that meets the requirements (what, 5 fetches inside of x
seconds?).
Then there is a second cache trigger. And that is some number of
hits on a library with some number of modules already cached, VLF
then starts caching any module requested...
[Sorry, a bit hazy on the exact numbers -- did not commit them to
memory.]
And I can see behavior that "backs this" when manually monitoring
using MFM.
The exception being when you cross the 90% utilization mark...
Then trim is forced, so that the now eligible requested module
can be put into cache. So those modules eligible for trim get
marked (NOTE, that is MARKED) for deletion. If one of those
modules gets requested before the "delete" cycle hits, the delete
flag is turned off.
More to tuning this sucker than I really wanted to get into.
Hence my prior comment about a certain ISV and their products
that pre-date LLA (Library Look Aside, not sure about Link List
Lookaside) and VLF.
Regards,
Steve Thompson
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
