Basil Fernie wrote:
> Hi Kris, Al, Herbert et al (but wait, you're in the list already aren't
> you?)
> 
> Thanks for the sundry somewhat-conflicting contributions concerning the
> operation of swapper.dat. One thing is for sure, it does *not* serve merely
> as an extra chunk of memory, sitting on HDU, this would not accomplish the
> function of "swapping" which I think Al's numbered list
clarifies well. One
> interpretation of Kris' explanation could be that, let's say in rough terms,
> you have 128MB RAM and you're using Open Office and between OS and OO
> they're using up 120MB; now you want to load a presentation into OO which
> totals 20MB; then 12MB of the presentation, let's say the last 12 pix, goes
> and sits on the hard drive in swapper.dat. Not too many objections so far,
> but what about when you want to display the last picture? Does the call to
> the memory array where the pic is stored, way out beyond the limits of
> actual RAM, get translated directly into a call to the file system - hpfs
> for argument's sake? No, I don't think so, I think it gets intercepted by
> the swapper.dat driver that says, OK, some portion of my swapper.dat is
> needed in RAM, so I'll first write out a chunk from RAM into swapper.dat,
> enlarging the file if necessary, to make room for the desired block to come
> into RAM; then I'll copy the block from swapper.dat into the
> recently-vacated space in RAM and juggle the memory call's pointer
> accordingly and hand it over to the memory driver.
> 
> Now there's a bit of potential conflict between Al and Herbert about the
> size of the smallest chunk of memory that gets handled in this way, it's not
> clear whether it's 16KB or 4KB, Herbert's definite about 4KB but Al is
> hinting at 16KB, but that's not life-threatening. I think the principle is
> clear and it makes sense to me, not that it ever hasn't.
> 
> But Al's point 4 (and 5) raises a serious issue: is a memory-block marked
> either in-use or available, or is it further marked as to frequency or
> recency of access by a particular process (which would be cleared when the
> app is flushed from memory on completion)? Because if its only mark is a
> simple YES/NO flag, then point 5 seems impossible to implement. If it has an
> associated frequency- or recency-count attached, then it becomes feasible to
> prioritise memory-blocks as candidates for such activities as swapping and
> caching. Which then leads us back to the question, what policies are in
> place to govern such prioritising? And do these policies enable cache-RAM
> preferential access to swapper.dat?
> 
> Al's experience that swapper.dat stopped growing once he got past 192K (are
> you sure it wasn't MB if it was RAM, Al? I had 640KB of RAM in an Olivetti
> M21 back in 1985 already) reflects, I would think, a particular pattern of
> usage of a particular set of applications and typical datafile sizes. I can
> quite visualise usage scenarios in which Herbert's 512MB of RAM generate a
> 1GB swap-file. But now I ask (and I'm sure I read the answer many years ago,
> but be so kind as to humour me, my memory-retrieval rate is getting worse
> than some people's PCs') what the actual addressing limits are: is 4GB the
> absolute total max for both normal RAM and virtual RAM (swapper.dat)
> combined, or do they own separate address spaces with some kind of
> intervening translation table?
> 
> For the record, I have a plain-Jane 32MB swapper.dat residing on drive H:,
> which also stores archival copies of the Star Office CD etc,
> and 512MB of RAM. I never experience growth of swapper.dat although I
> sometimes do quite hairy multiple activities, stacking big applications on
> top of each other. I suspect swapper.dat never gets used, but I don't
> begrudge the tiny portion (c. 1,5%) of the HDU that it takes up, regarding
> it as an insurance premium for the just-in-case day. I also suspect that the
> Warp4 memory-manager is clever and mature enough not to waste much time on
> thinking about whether to send something out to swapper.dat, although at
> that particular layer there must be something of a performance hit because
> every memory request must be checked. So Kris' setting could probably be
> appled with little risk.
> 
> Here's to (far) too much RAM,
> 
> Basil
> 
> 
> ----- Original Message ----- 
> From: 
> To: 
> Sent: Friday, March 19, 2004 6:56 PM
> Subject: Re: Os2.ini
> 
> 
> 
>>Fri Mar 19 2004 08:56 am
>>
>>Hi Basil & others:
>>
>>Swapper.dat is for computer memory only.
>>
>>Here when I went to greater than 192K swapper.dat no longer would grow.
>>
>>How to judge needed memory:
>>
>>Start with 128K ram after running for a while CHECK size of swapper.dat .
> 
> Here it was about 70K Add next size of memory (128K) for a total of 256K and
> no more growth in swapper.dat
> 
>>NOTE: If you delete swapper.dat it will be recreated and sometimes not
> 
> where you want it. You cansay where it will be in config.sys
> 
>>HOW IT WORKS:
>>
>>1- Memory is divided into pages (16K chunks)
>>2- as memory is used OS/2 keeps tab on what is used and not used
>>3- pages not in use are maked.
>>4- nothing happens UNTILL you run out of physical memory.
>>5- OS/2 looks for memory that hasn't recently been used and writes it to
> 
No.

OS/2 uses a page size of 4 KB. So memory gets broken int pieces of 4 
KB each.

When there all available RAM is used and a bit more RAM is needed then 
the memory manager has some ways:
- find the least used chunk of memory
- if this chunk is not moveable: find another one
- if this chunk is discardable discard it
- if this chunk is not discardable then write it to swapper
   - when not prior written:
     - find a block of free, unassigned space in swapper
     - is ther none: extend swapper and use the new
       allocated space for
   - write the page from memory to swapper
- assign the new won space to the process it
   requires the RAM.
- load the data required from either
   - codepages from .exe or .dll (as these are discardable)
     they got never written to swapper
   - swapper.dat when already swapped out
   - from data space in .exe or .dll when first time requirement

Another ownstanding process in memory manager will cyclic scan 
swapper.dat for space not assigned to some active process.
When an process is active the one times reserved space for
one of its assigned pages are never freed in swapper.
when an proces has ended the space is holded for a while because
the user may start that process again. After this while the
spaces the process has used in swapper gets freed. Free chuncs
gets concatenated to give one singe big free room. If free
room ends with end of swapper: swapper will be shrinked because
it may now bigger as needed in future.
This results sometimes in that even a 1GB swapper never shrinks
and on another time that swapper shrinks back to its inital size,
depending on what data is on the end. Assigned data gets never
reallocated because it has an defined place. Free space on the
end of swapper can be easely given back to free space on disk.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Upgrade to 128-bit SSL Security!
http://us.click.yahoo.com/LPJzrA/yjVHAA/TtwFAA/E8folB/TM
---------------------------------------------------------------------~->

 
Yahoo! Groups Links

 To visit your group on the web, go to:
     http://groups.yahoo.com/group/os2user/

 To unsubscribe from this group, send an email to:
     os2user-unsubscribe{at}yahoogroups.com

 Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/
 


---