Thanks for all of the replies that I have received.  One of my concerns
is that we have at this point only done one application on Linux.  That
application was a new type of work load.  That we are planning on doing
next is move some work load from other platforms over to the mainframe.
My concern is that there are enough challenges with moving the work load
without also trying to do the DCSS stuff at the same time.


Thanks
Paul 

-----Original Message-----
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
barton
Sent: Sunday, June 03, 2007 10:40 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question about using z/VM DCSS for sharing code under Linux

I pretty much disagree.  Tools are there, lots of storage savings
possible.   One system I
look at, i expect to save over 1/2 GB of REAL storage with xip
implementation.  machines do not need to be identical, it just takes an
understanding of how to implement, what to include and specifically how
to measure it.



David Boyes wrote:

>> I was wondering how many people are using DCSS to share code under 
>>Linux?  At this time we are looking at about 12 to 15 Linux guest 
>>divided across two lpars.  It is my understanding the Linux guest will

>>be running WebSphere and Oracle.  I have found some information on 
>>setting up the environment.  The doc talks about performance gains and

>>memory savings that has some people here interested in looking at
>
> DCSS.
>
> Unless you have a larger number of *exactly* identical guests (>50 
> would be my starting point to look at this) delivering the same 
> function within the same VM system with R/W data stored in other 
> virtual machines (ie, remote databases), it's probably not worth it.
>
> What I've observed so far with DCSS-based filesystems is at best it 
> gives you some I/O avoidance (and correspondingly, some reduction in 
> caching bloat) on the executable portions of the applications. You'll 
> still see the virtual machines bloat up to their maximum defined size;

> it'll just take longer for the kernel to dirty up the "spare" memory 
> with data pages.
>
> Given the current state of the DCSS and XIPFS tooling, it's difficult 
> to manage systems that use the DCSS/XIP function, and you need to 
> install the applications in ways to rigidly separate R/O and R/W code
and data.
> This is not trivial to accomplish, especially with the two 
> applications you mention (it can be done, but it requires major 
> surgery and an intimate knowledge of what the apps puts where and what

> it is actually up to during runtime).
>
> Also, most of the memory bloat in those two applications is in private

> R/W memory structures, which won't really benefit at all from the
DCSS.
>
> Both DCSS and XIP functions are interesting ideas, but until the 
> tooling gets more sophisticated, they're probably not going to see
much use.
>


----------------------------------------------------------------------
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

----------------------------------------------------------------------
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

Reply via email to