I thought as much. Thank you, Barton.
Bob
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Barton
Robinson
Sent: Friday, April 20, 2012 1:46 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Central vs. Expanded Storage - current recommendation
please
please make 20% of your storage ExStore. This only matters if you are
storage constrained, so benchmarking differences when there are no
constraints will not show a difference. When you become storage
constrained, the 20% ExStore will easily show better performance.
Richards, Robert B. wrote:
I was wondering what the latest recommendation is on managing storage for z/VM
with several dozen Linux guests.
We are moving a z/VM lpar (let's call it VM2) with 12.3GB CS and 2.3 ES to
another CEC. Presently, VM2 competes with VM1 and a normally idle VM3 sysprog
lpar for usage on one IFL.
On
On Saturday, 11/04/2006 at 05:27 ZE8, John Summerfield
<[EMAIL PROTECTED]> wrote:
> Your other reply addresses that; perhaps you should visit a stationer
> any buy yourselves a round tuit?
They're sold out. :-( They have square tuits, triangular ones, even
7-sided ones. But no round ones. (Wel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Summerfield wrote:
> Your other reply addresses that; perhaps you should visit a stationer
> any buy yourselves a round tuit?
Why not send him a present for crimble
(http://www.oed.com/bbcwordhunt/crimble.html):
http://www.quantumenterprises.co.
Alan Altmark wrote:
On Saturday, 11/04/2006 at 05:01 ZE8, John Summerfield
<[EMAIL PROTECTED]> wrote:
I had thought that expanded storage, when introduced (late 80s?) was a
bandaid to cover other problems.
When first introduced, expanded storage was made from memory chips that
couldn't opera
Unless I remember wrong, expanded storage was (as already stated)
composed of slower memory, and was only addressable on 4K boundaries.
The simplified addressing scheme made for less expensive storage, and
the timestamping made the paging algorithm work better.
J. Leslie Turriff
VM Systems Progr
Mark Perry wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi John,
many thanks for that excellent URL, it's an exact an answer to my
question :-)
The explanation does however lean on z/VM's algorithms as being the
potential need for Expanded storage, and the 2GB problem went away with
z/V
On Saturday, 11/04/2006 at 05:01 ZE8, John Summerfield
<[EMAIL PROTECTED]> wrote:
> I had thought that expanded storage, when introduced (late 80s?) was a
> bandaid to cover other problems.
When first introduced, expanded storage was made from memory chips that
couldn't operate reliably at central
David Boyes wrote:
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?
[snip]
Put another way, couldn't an OS such as z/VM, perform better using only
On Friday, 11/03/2006 at 09:35 CET, Mark Perry <[EMAIL PROTECTED]>
wrote:
> 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?
Ah, I get it now.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Boyes wrote:
> I'd really
> rather they NOT mess with it if it isn't necessary.
Hi Dave,
I merely wished to understand a little better. Thanks for your honest
opinion.
A rewrite is not necessary :-)
Mark
-BEGIN PGP SIGNATURE-
Version:
> 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?
> [snip]
> Put another way, couldn't an OS such as z/VM, perform better using only
> Central S
-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
On Friday, 11/03/2006 at 07:54 CET, Mark Perry <[EMAIL PROTECTED]>
wrote:
> The explanation does however lean on z/VM's algorithms as being the
> potential need for Expanded storage, and the 2GB problem went away with
> z/VM 5.2.
>
> An OS that need to cache "active" working sets, only needs to do
On 11/3/06, Mark Perry <[EMAIL PROTECTED]> wrote:
An OS that need to cache "active" working sets, only needs to do so when
it runs out of sufficient Central storage. By moving Central storage to
Expanded storage one only exacerbates the problem.
I'm not sure you draw the right conclusion, but
t: Re: [LINUX-390] Central vs Expanded Storage
* PGP Signed by an unknown key: 11/03/2006 at 01:42:26 PM
Hi Steve,
the faster option is "not to page", which is an option if you have more
real memory i.e. Central storage.
Paging *OUT* from Expanded Memory, if I understand correctly,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi John,
many thanks for that excellent URL, it's an exact an answer to my
question :-)
The explanation does however lean on z/VM's algorithms as being the
potential need for Expanded storage, and the 2GB problem went away with
z/VM 5.2.
An OS that n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Steve,
the faster option is "not to page", which is an option if you have more
real memory i.e. Central storage.
Paging *OUT* from Expanded Memory, if I understand correctly, requires
first bringing the data into Central storage so that it can then
Here is a pretty good webpage that describes the reasons for VM's need for
expanded storage.
http://www.vm.ibm.com/perf/tips/storconf.html
John
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to
helps a little.
Regards,
Steve G
Mark Perry <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port
11/03/2006 01:15 PM
Please respond to Linux on 390 Port
To: LINUX-390@VM.MARIST.EDU
cc:
Subject: Central vs Expanded Storage
-BEGIN PGP SIGNED MESSAGE-
Hash:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- From Kevin's email (below) "16GB storage (12GB Central, 4GB Expanded)"
Forgive the digression, but this is something I have been meaning to ask
IBM's z/VM guys for some time now
Why does z/VM still use Expanded storage? (z/OS no longer support
22 matches
Mail list logo
