IBM has talked about the excess Share problem as well,
see chart 23 in
http://www.vm.ibm.com/devpages/bitner/presentations/vmup2011.pdf
And we are working on it. I think an assertion that it happens
all the time is a little overboard. Now that we understand the
problem better, I can say everyone ma
Am I the first?
That is what we were taught with 390 systems.
You also didn't want your communications region to be paged out (set reserved
for those).
You always gave communications very high priority. You didn't want your 3270
traffic waiting. If, due to resources, you needed to wait, you wa
sweet spot of CPU it takes some finagling.
David
Original Message
Subject: Re: Set Share Relative
From: Scott Rohling
Date: Tue, June 14, 2011 6:51 pm
To: LINUX-390@VM.MARIST.EDU
No worries, Sir Rob - I seem to be especially cranky today. Excellent
paper
and explanation of
No worries, Sir Rob - I seem to be especially cranky today. Excellent paper
and explanation of relative share - and a much better answer then the
simplistic HELP explanation. I'll refer to this in the future... Thank
you!
Scott Rohling
On Tue, Jun 14, 2011 at 2:56 PM, Rob van der Heij <
rvdh..
On Tue, Jun 14, 2011 at 7:57 PM, Scott Rohling wrote:
> My statements were based on the help for CP SET SHARE.. my comments on math
> were somewhat tongue in cheek - but since this is a relative value - 100 is
> as good as any other to base things on.. set all your guests to 7 and use
> increme
I really despise the "system defaults" of REL 1500, or REL 5000. They
seem (were) provided by someone ignorant of how the scheduler actually
works.
Rob has a nice paper showing the damage. Though ibm might try and code
around how this damage impacts your system, changing these defaults to
realis
My statements were based on the help for CP SET SHARE.. my comments on math
were somewhat tongue in cheek - but since this is a relative value - 100 is
as good as any other to base things on.. set all your guests to 7 and use
increment of 3 if you like. No idea at all by what you mean by 'polit
On Tue, Jun 14, 2011 at 5:49 PM, Scott Rohling wrote:
> Depends on how granular you want to be, but I tend to go in 100
> increments... helps make the math easier. At 200 you get twice as much
> access to resources as those at 100, at 1500, 15 times, etc. If that seems
> like too much of a ju
You would think that's how it works, but it doesn't. I'm sure our friends
and Velocity will chime in.
On Tue, Jun 14, 2011 at 11:49 AM, Scott Rohling wrote:
> Depends on how granular you want to be, but I tend to go in 100
> increments... helps make the math easier. At 200 you get twice as muc
Depends on how granular you want to be, but I tend to go in 100
increments... helps make the math easier. At 200 you get twice as much
access to resources as those at 100, at 1500, 15 times, etc. If that seems
like too much of a jump (twice as much) -- then go fractional. 150 for 1.5
times th
Is there a rule of thumb on setting relative shares for zVM users? Default has
them at 100, we have increased important ones to 200. I noticed the system
users have very high shares, e.g. 1500. So, when you are prioritizing, or
de-prioritizing should you go in small incremental (25-50) or lar
11 matches
Mail list logo