OS/2, eCS & ArcaOS - Technical > Storage

PMSHELL

(1/4) > >>

Remy:
Did some of you get storage issue ?
I saw that as soon my shared memory gors below 10Mb, I have display freeze and fullscreen mode fails.
I check free memory using SL.

I tried to kill PMSHELL used by WPS which results into a WPS restart and 70MB freed memory into share storage.
How to configure to have shared memory freed as soon it is no more used ?
Thanks     

Doug Bissett:
I wouldn't call it a "storage" issue. It is a shortage of lower shared memory space. I find that it is only a matter of a few minutes, until my system crashes, when lower shared memory drops below 100 MB (it is probably already dead if it shows 10 MB). To avoid the problem, I add the line"

--- Code: ---VIRTUALADDRESSLIMIT=2560
--- End code ---
to CONFIG.SYS. Some systems will be able to use 3072, but, apparently, some other systems can't use that. It only increases the available upper shared memory anyway.

Doing that does not actually change the problem, without taking further steps to mark some things to actually use upper shared memory space (there are some fixes in the ArcaOS kernel for upper shared memory support too). The easiest thing to set to use upper shared memory space, is Apache Open Office. In the Extras folder, there is a tool to set it to use upper shared memory (some experimenting may be required). If you do that, you may find that there will be a LIBC problem (usually not obvious), if you close Open Office more than once. To avoid that, use the Quickstart thing, to prevent it from actually closing.

You should also realize, that shared memory may fragment. If the largest fragment is 5 MB, and some program needs 5.5 MB, you are dead in the water. If the program is properly written, to check if it actually got the requested memory, it will probably just crash the program. If it doesn't check (apparently, most programs don't), and tries to use it anyway, it usually causes what you describe.

Roderick Klein:

--- Quote from: Doug Bissett on July 29, 2018, 10:54:07 pm ---I wouldn't call it a "storage" issue. It is a shortage of lower shared memory space. I find that it is only a matter of a few minutes, until my system crashes, when lower shared memory drops below 100 MB (it is probably already dead if it shows 10 MB). To avoid the problem, I add the line"

--- Code: ---VIRTUALADDRESSLIMIT=2560
--- End code ---
to CONFIG.SYS. Some systems will be able to use 3072, but, apparently, some other systems can't use that. It only increases the available upper shared memory anyway.

Doing that does not actually change the problem, without taking further steps to mark some things to actually use upper shared memory space (there are some fixes in the ArcaOS kernel for upper shared memory support too). The easiest thing to set to use upper shared memory space, is Apache Open Office. In the Extras folder, there is a tool to set it to use upper shared memory (some experimenting may be required). If you do that, you may find that there will be a LIBC problem (usually not obvious), if you close Open Office more than once. To avoid that, use the Quickstart thing, to prevent it from actually closing.

You should also realize, that shared memory may fragment. If the largest fragment is 5 MB, and some program needs 5.5 MB, you are dead in the water. If the program is properly written, to check if it actually got the requested memory, it will probably just crash the program. If it doesn't check (apparently, most programs don't), and tries to use it anyway, it usually causes what you describe.

--- End quote ---

If I did not understand you correctly Doug. You typed:
"without taking further steps to mark some things to actually use upper shared memory space".
However GCC applications already store data (such as browser cache) into the high area.

For Remy:

The real killer is the size of the large DLL's that get loaded this can fixed by using a tool to mark the code segments to load high. Do this for Firefox DLL's, THunderbird AND Open Office.  Do not mark the datasegments high of the DLL.
Also make a backup of your DLL's before doing this.  There is a tool from Yuri called high512 that can mark the DLL's high.

You are most likely not the first and the last OS/2 user to expereince these type of lockups. It might be usefull to report this in a ticket to AN ?

Roderick

David McKenna:
 I wonder if it would be possible in theory to create a 'memory defragmentation' daemon that monitors memory and warns when fragments get below a specified size (or even better, defrags when needed)?

Andi B.:
I would say no. Of course it's possible to monitor memory usage (above512 and others) and fragmentation (interpret Theseus memory information and calculate the gaps) but what is the value when you should be warned about to 'low' memory?

From the kernels POV memory is not to 'low' until an application request memory and the kernel can not fulfill this request. Not earlier. Moreover even if you think some memory is low (as above512 tells you) you do not know if there is some large block already freed by some application somewhere. The kernel knows this can be given to another application if requested  (interpret Theseus and you may know too). But it depends on the value of memory the application requests. You don't know beforehand how much memory f.i. a java script wants to allocate before this specific one runs and makes the request to the OS.

When it comes to defragmentation it's simply not possible AFAIK. The kernel would need to to tell some application to free some specific memory. But neither the kernel nor the applications have implemented such algorithm.

Navigation

[0] Message Index

[#] Next page

Go to full version