× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> -----Original Message-----
> From: James Rich [mailto:james@xxxxxxxxxxx]
> Sent: Wednesday, November 24, 2004 5:38 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: Laymans explaination for single level store?
> 
> 
> On Wed, 24 Nov 2004 CWilt@xxxxxxxxxxxx wrote:
> 
> > First off, David asked for a layman's explanation.  If you 
> want to discuss
> > technical details, perhaps we should start a new thread.
> 
> No, keep this thread going (imo).
> 
> > But you are correct that in some cases it makes sense that 
> a copy is made so
> > you can discard changes.  But that's the application level 
> you are talking
> > about, not the OS level.  Applications on the iSeries can 
> be written to work
> > with a temporary copy of a given object.  For instance, SEU 
> does this.
> 
> This is quite clearly correct.
> 
> > But that doesn't change the fact that no application can 
> access anything not
> > in its VM address space.
> 
> This is true of all systems and applications (with some 
> exceptions like 
> the raw device linux and other systems have to accomodate 
> oracle).  The 
> reason this is true is that the OS (or more precisely the 
> kernel) is that 
> part of the system that is resposible for retrieving the data 
> from all the 
> various devices and getting it to the applications (and vice versa). 
> Applications ask the kernel for memory or disk files or what 
> have you. 
> The kernel does what it can and then makes that data available.
> 
> > So when dealing with large data files, you have two types 
> of swapping going
> > on.
> > 1) The application is swapping data from its VM address 
> space to/from the
> > actual disk file
> 
> False.  Applications do not swap.  The kernel does.  
> Applications do not 
> read the disk.  Applications do not allocate swap space.  The 
> kernel does 
> all of this.  But that is exactly what you are saying is type 
> two below. 
> This type one is non-existent.

Not false.  Swap may have been a confusing choice of words.  But what I am
talking about is the movement of data back and forth between the disk and
the application's VM address space.  Certainly the kernel does the work, but
it does it _ONLY_ at the request of the application.

This absolutely has to happen when the application is dealing with data
larger than what can fit in it's VM address space.  Remember, on a 32bit
CPU you are only dealing with a 2GB VM address space.  Normally, it happens
all the time even with data less than 2GB since it would kill performance of
the rest of the processes if you actually tried to use all 2GB of your
assigned VM address space.


> 
> > 2) The OS is swapping VM pages of running applications 
> between main memory
> > and the swap file on disk.
> 
> > With single level store, #2 from above is the only swapping 
> happening. You
> > can see that single-level store has performance benefits.
> 
> Type two is the only type that happens regardless of single 
> level store. 
> Single level store has benefits.  Performance and sharing may 
> be among 
> them.  But not for the reasons outlined above.
> 


I already showed that there are indeed two different types of back and forth
data movement, aka swapping.  Microsoft agrees: "All that has happened is
that the physical I/O to the database files has been traded for physical I/O
to the swap file."

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/architec/8_
ar_sa_4rc5.asp


1) Movement between the disk (file system) and the applications VM address
space.
2) Movement of VM pages between physical RAM and the swap file on disk.


Given that there are two types, it should be obvious why SLS benefits from
only having one type.


Charles

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.