The partition is the easy part, just follow the model of the DUMP space in 
spool. But how, if you cannot even get a command entered by a logged on user, 
are you going to be able to make use of it?
I think that the idea of putting the collar on the runaway process or guest has 
to be solved first. Then, it might be possible to take corrective action from 
already existing userids such as OPERATOR, obviating the need for partitioning. 


Regards, 
Richard Schuh 

 

> -----Original Message-----
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark
> Sent: Sunday, September 20, 2009 11:03 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Storage Management Enhancement Ideas
> 
> On Sunday, 09/20/2009 at 04:26 EDT, Rob van der Heij 
> <rvdh...@velocitysoftware.com> wrote:
> > On Sat, Sep 19, 2009 at 6:21 PM, John P. Baker 
> > <jbaker...@comporium.net>
> wrote:
> > 
> > > I recommend that the idea of splitting page space into multiple 
> > > pools
> be
> > > considered, where individual users can be assigned to different
> pools.  For
> > > the purposes of discussion, let us consider that following
> enhancement:
> > 
> > I don't like the idea to use only a subset of your paging 
> capacity for 
> > part of the workload. It's not just about space but also about 
> > throughput. This is imho a very complicated approach to exclude some
> > (small) important users from an OOM killer. The real question is 
> > whether you can do an OOM killer at all and achieve 
> something useful 
> > by doing so.
> > 
> > Most performance tuning gets harder when you split resources and 
> > consumers in different groups and manage them separately. 
> Sharing is 
> > easier with large numbers.
> 
> And does not address the core issue: At some point, there is 
> a shortage of resources.  How should CP respond?
> 
> o Deny the request?
> o Wait for the resources to be available? 
> o Steal the resources from someone else?
> 
> You can partition and reserve all the resource you want, but 
> eventually you run out.
> 
> Alan Altmark
> z/VM Development
> IBM Endicott
> 

Reply via email to