> Right, you'd have to be careful since you (briefly) increase your
> memory requirement. I only recommend that when the cause of the
> swapping is gone already and Linux has released most slots on the swap
> disk again. CP would continue to care for the pages even though Linux
> does not need the
On Wed, Jun 22, 2011 at 4:07 PM, Bill Holder wrote:
>> But since Linux does know how to evacuate swap space, you can define a
>> new VDISK for swap and free the old VDISK. Once you detach it, the
>> slots on page space will be freed up. Whether it makes sense to shake
>> up your memory reference p
> But since Linux does know how to evacuate swap space, you can define a
> new VDISK for swap and free the old VDISK. Once you detach it, the
> slots on page space will be freed up. Whether it makes sense to shake
> up your memory reference patterns like that is an entirely different
> issue...
>
>
On Tue, Jun 21, 2011 at 10:31 PM, Bill Holder wrote:
> and it also
> won't help with CP system-owned pages (including vdisk pages, for what it's
> worth), which
> cannot be locked via the CP LOCK command.
But since Linux does know how to evacuate swap space, you can define a
new VDISK for swap a
> I think that would probably break NSS/DCSS processing, since those can
appe=
> ar in multiple address spaces, and you'd need to fix all those references
t=
> oo.
That does indeed add complexity, but is solvable - for shared NSS/DCSS
pages, the "owning entity" is the NSS/DCSS itself, that's what
> Just a perhaps crazy idea.
> - Add new page volumes
> - drain all old page vlumes to stop adding new data there
> - for each Linux, one at a time change the reserved memory to the same as
m=
> emsize
> (for this to work, z/VM now must restore all paged memory into real
memor=
> y)
> - wait unti
> Just a idea, but what if we put the "back link" on the DASD page (I don't
> know much about the structure of the page, but I think there's a header
> there somewhere), not on central memory? We would only have to read the
back
> link on the page header on DASD and we would know where the page is,
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> Agblad Tore
> Sent: Tuesday, June 21, 2011 9:37 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: z/VM page space
>
> Just a perhaps crazy idea.
> - Add new page vol
> Just a idea, but what if we put the "back link" on the DASD page (I
> don't
> know much about the structure of the page, but I think there's a header
> there somewhere), not on central memory? We would only have to read the
> back
> link on the page header on DASD and we would know where the page
.agb...@volvo.com
http://www.volvo.com/volvoit/global/en-gb/
From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] On Behalf Of Mauro Souza
[thoriu...@gmail.com]
Sent: Tuesday, June 21, 2011 15:20
To: LINUX-390@VM.MARIST.EDU
Subject: Re: z/VM page space
Just a idea,
Just a idea, but what if we put the "back link" on the DASD page (I don't
know much about the structure of the page, but I think there's a header
there somewhere), not on central memory? We would only have to read the back
link on the page header on DASD and we would know where the page is, migrate
On Monday, 06/20/2011 at 08:56 EDT, Clovis Pereira
wrote:
> At least, we seeded the idea.
The requirement to provide this function has been on the books and on VM
Development's collective conscience since 1990. :-( *Everyone* runs
into a dasd migration/reclamation project at some point that fo
Thanks, Bill.
Good explanation, enough for me.
At least, we seeded the idea.
Best regards,
__
Clovis
From:
Bill Holder
To:
LINUX-390@vm.marist.edu
Date:
17/06/2011 18:39
Subject:
Re: z/VM page space
Sent by:
Linux on 390 Port
> Hi, People.
&
> Hi, People.
> My cent to this discussion.
> We are talking about pages on dasd, not pages in memory.
> So, these pages already was swapped. Except some control pages, I think.
>
> To free the dasd, VM will need:
> Know what pages are on the specific dasd. It can be done by "Page out"
> routines,
One page must be the minimum. The memory fairies recently visited here so we
have 6 systems that are undercommitted for memory at the moment. Each of them
has exactly 1 page in use.
Marcy
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Bill
H
> I'm curious about why CP would write pages immediately after IPL? At
that
> point, there is likely sufficient memory and paging isn't needed.. so
why
> not wait until it is? I'm sure there's a good explanation - just
> wondering...
>
> Scott Rohling
I can't really speak for how good the exp
is not so simple to implement, but looks like viable.
What do you, the experts, think about?
__
Clovis
From:
Scott Rohling
To:
LINUX-390@vm.marist.edu
Date:
17/06/2011 12:59
Subject:
Re: z/VM page space
Sent by:
Linux on 390 Port
>
>
>
>
>
>
>
> Hi David - one further comment - although it is indeed typical to see some
> CP owned pages written immediately after the system IPL, it's really not
> safe to make the assumption that that is the only time it will happen, In
> particular, the ISFC and Virtual Free Storage spaces are pagea
On 6/17/11 10:03 AM, "Bill Holder" wrote:
>That would certainly prevent any page allocation on paging volumes.
>Just be aware that if you do need to depopulate the spool volumes
>that paging overflowed to, you'll have the same problem - the existing
>techniques for moving spool (SPXTAPE and such)
> evil thought. Come up without paging space - paging early life will go
> to spool. Have the autolog
> machine bring up the real page volumes. Moving spool a whole 'nuther
> thing - so who cares?
> David
That would certainly prevent any page allocation on paging volumes.
Just be aware that if yo
ed need to update standalone dumping to go to DASD.
David
Original Message
Subject: Re: z/VM page space
From: David Boyes
Date: Thu, June 16, 2011 11:59 pm
To: LINUX-390@VM.MARIST.EDU
On 6/16/11 7:36 PM, "David Kreuter" wrote:
>evil thought. Come up without pagi
On 6/16/11 7:36 PM, "David Kreuter" wrote:
>evil thought. Come up without paging space - paging early life will go
>to spool. Have the autolog
>machine bring up the real page volumes.
Hmm. You know, that might just work in these days of gigabyte real memory
configurations. Still no way to force
evil thought. Come up without paging space - paging early life will go
to spool. Have the autolog
machine bring up the real page volumes. Moving spool a whole 'nuther
thing - so who cares?
David
Original Message
Subject: Re: z/VM page space
From: David Boyes
Date: Thu,
ssage-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Bill
Holder
Sent: Wednesday, June 15, 2011 4:44 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: z/VM page space
> We ran into the same issue. Our page space got up to 70% - 80% and we
> saw performance "go down t
On 6/15/11 10:02 PM, "O'Brien, Dennis L"
wrote:
>If you have the luxury of an IPL, this is easy. Just put Drain records
>in SYSTEM CONFIG for the volumes that you don't want pages on. CP won't
>put anything on them, not even its own pages. The original question was
>whether there's a way to mo
>Yeah, I figured as much, although if you could get the system up and drain
>the volume, then those pages would be ineligible for the drained pack too,
>right? The "just after IPL" case is IMHO the hardest case because there's
>no way to gain control before that can happen (it frequently happens ev
On 6/15/11 5:55 PM, "Bill Holder" wrote:
>On Tue, 14 Jun 2011 11:03:49, "David Boyes" wrote:
>
>> Problem is still going to be dealing with pages written during the first
>> few seconds after an IPL by CP itself.
>
>Hi David - one further comment - although it is indeed typical to see some
>CP o
On Tue, 14 Jun 2011 11:03:49, "David Boyes" wrote:
> Problem is still going to be dealing with pages written during the first
> few seconds after an IPL by CP itself.
Hi David - one further comment - although it is indeed typical to see some
CP owned pages written immediately after the system IP
> We ran into the same issue. Our page space got up to 70% - 80% and we
> saw performance "go down the toilet". Our page volumes were on MOD-9's
> but only a third of each volume was usable because the page space had
been
> defined as a MOD-3.
> We tried the DRAIN and that stopped using that page
.
It is not worth the bother but there it is, a thought.
David
Original Message
Subject: Re: z/VM page space
From: David Boyes
Date: Tue, June 14, 2011 12:03 pm
To: LINUX-390@VM.MARIST.EDU
On 6/14/11 10:54 AM, "Marcy Cortes"
wrote:
>The question is why do you
On Tuesday, 06/14/2011 at 11:36 EDT, Sam Bass
wrote:
> Do you think IBM will think about adding a 'page delete' feature so you
can
> migrate page volumes to another disk subsystem so you don't have to
shutdown
> all of the guest and z/VM? It sure would be handy.
> I was hoping to move all of the
pany
> > 121 E. Park Square
> > Owatonna, MN 55060
> > (507) 455-5200
> > ext. 4555706
> >
> >
> > -Original Message-
> > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> > Marcy Cortes
> > Sent: Tuesday, June 14,
ort [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> Marcy Cortes
> Sent: Tuesday, June 14, 2011 9:54 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: z/VM page space
>
> The question is why do you need to know?
> If you are running out of space, add more.
> If you can't
On 6/14/11 10:54 AM, "Marcy Cortes" wrote:
>The question is why do you need to know?
Short version: to know which guests to recycle to clear an old paging
volume without having to take a CP IPL just to get old pages off a paging
volume.
Problem is still going to be dealing with pages written d
x on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan
> Altmark
> Sent: Monday, June 13, 2011 6:02 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: z/VM page space
>
> On Monday, 06/13/2011 at 03:48 EDT, Sam Bass
> wrote:
> > I am migrating from one disk
07) 455-5200
ext. 4555706
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy
Cortes
Sent: Tuesday, June 14, 2011 9:54 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: z/VM page space
The question is why do you need to know?
If you are running out of space, add m
---
>
> SPOOLCHN is available from VMTOOLS and http://www.vm.ibm.com
>
> Richard Ross
>
> _________
>
> __
> Clovis
>
>
>
> From:
> Scott Rohl
The question is why do you need to know?
If you are running out of space, add more.
If you can't, you'll have to shut virtual machines down. Start with the
largest ones.
BTW, don't let your paging space get more than 50% full or performance goes
down the toilet.
Marcy
-Original Message-
d have less
to do on the weekend when I move the z/VM res/spool/page/guest volumes.
Sam Bass
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan
Altmark
Sent: Monday, June 13, 2011 6:02 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: z/VM page space
O
Ross
_
__
Clovis
From:
Scott Rohling
To:
LINUX-390@vm.marist.edu
Date:
14/06/2011 10:32
Subject:
Re: z/VM page space
Sent by:
Linux on 390 Port
Performance Toolkit can
> In z/VM is there a way to tell who or what is using that page space?
Coming from the z/OS world
> I know there was a way to display show was the biggest user of the page
slots. Is there a way
> to do that in z/VM?
I am unaware of any way to tell which users (or other pageable entities)
have the
nsurance Company
> 121 E. Park Square
> Owatonna, MN 55060
> (507) 455-5200
> ext. 4555706
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan
> Altmark
> Sent: Monday, June 13, 2011 6:02 PM
> To: LINUX-390@VM.MARIST
(507) 455-5200
ext. 4555706
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan
Altmark
Sent: Monday, June 13, 2011 6:02 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: z/VM page space
On Monday, 06/13/2011 at 03:48 EDT, Sam Bass
wrote:
> I am migrat
On Monday, 06/13/2011 at 03:48 EDT, Sam Bass
wrote:
> I am migrating from one disk subsystem to another.
> I know that you can add PAGE volumes via DEF CPOWNED after you have
formatted a
> volume and ATT *unit* SYSTEM.
>
> Is there a way to do a 'page delete' like you can in z/OS so you can
move o
Sam,
You can take a look at the CP DRAIN command for DISK. You can tell CP to
stop using a device this way.
Aria
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Sam
Bass
Sent: Monday, June 13, 2011 3:47 PM
To: LINUX-390@VM.MARIST.EDU
Subject: z/V
45 matches
Mail list logo
