-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Rob and Alan, email is not always the best medium for conversation (unless you are extremely verbose, and that to is self defeating.)
I do understand the webpage's explanation on LRU, special timestamping and caching, and I do *trust* you when you state that z/VM works better (under certain conditions) with some Expanded storage. I guess what I fail to understand is why it has to be Expanded storage, couldn't you obtain even better results using a (fixed) cache of Central storage in which to utilize your timestamped LRU algorithms? Is it simply a matter that the code exists for Expanded storage, so you continue to use it rather than write new code that could also benefit from the ability to write from Central to DASD directly? Put another way, couldn't an OS such as z/VM, perform better using only Central Storage if the code were written specifically to target Central storage. - Please note the word "could" :-) The key point I am trying to understand is not if z/VM performs better using Expanded storage (I believe you!), but *could* it be made to perform as good (or better) using only Central storage. For me Expanded storage is archaic, and if its use implies a reduction in Central storage then that is detrimental to *potential* performance of an OS. (z/VM's current coding excepted) Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFS6gZ+CA7PBRBnXQRAiijAKDtcwyl4uSZoiEbdPcygEOMKBmmQACgnZIt JKMxz2xVfDncf68QOJPfGcU= =1il4 -----END PGP SIGNATURE----- ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
