Carlos, Exactly the response I was looking for. After having to deal with the appalling memory management of other PC O/S you have answered the question perfectly. However, I now need to know is there a process that removes items from cache after a period of time or will available memory be used to cache continually without being flushed. Now my query comes down to "unused cache flush time" and "flush cache due to processing demands determination" Thanks Scott Carlos E. R. wrote:

The Monday 2007-05-07 at 07:25 +1000, Registration Account wrote:

...

...

For example I have 2 GIG of RAM currently and am thinking of changing it to 4 GIG. I understand that the kernel can use more file cacheing, but that is what I do not want to know. With the superior way the Linux Kernel manages Memory, if we remove the increased file caching ability will the Kernel be able to utilise the extra memory registers for processing.

I think you got it wrong... if there is more memory, programs will be able to use more memory, /if/ they request it. All unused memory will simply end up being used as cache.

If currently, with 2G, you see no swap used, increasing the ram will not give more memory to programs.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-05-09 at 10:29 +1000, Registration Account wrote:

Carlos, Exactly the response I was looking for. After having to deal with the appalling memory management of other PC O/S you have answered the question perfectly.

However, I now need to know is there a process that removes items from cache after a period of time or will available memory be used to cache continually without being flushed.

Memory used to cache some thing will stay that way unless there is a better use for it, as far as I know. If a program demands memory and there is not sufficient free memory, some cache will be freed instantly and used for that. Or, if new files are read, older cache will be reused for those new files. Roughly. Now, to learn the exact algorithm that decides all this you have to study the kernel... and it is a moving target. I don't know the details. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGQaOPtTMYHG2NR9URAt9sAJsEZA3NMqaAOGRKLhoydUhjnSYePACggAUS LqjcLmhWsuvpTU2OEbf4TJ4= =zyso -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

However, I now need to know is there a process that removes items from cache after a period of time or will available memory be used to cache continually without being flushed. The other answers you have received are correct, and very good answers. The tiny bit I will add is that viewing the memory from "top" for from "free" can be a little deceptive. Yes, there are very highly efficient kernel routines

On Tuesday 08 May 2007 19:29, Registration Account wrote: that maintain your memory... and they work very well, as Randall said. However, they *do not* free up memory in large chunks that you can *see* typically. The kernel uses free available memory for cache and other purposes and efficiently balances that with system and user demand, swap, etc. So, if you have 512M of ram, you will notice that it is mostly used... maybe swap is used, maybe not. If you have 1024M of ram you will notice that its mostly used... in other words, the kernel is going to "use" the memory you give to it... and you don't need to do *anything* to interfere with the processing. :) Run "top" from konsole and then give it the "s" command and change the processing update to .5 (thats point five). .... and then watch the buffers, cache, main ram etc.... -- Kind regards, M Harris <>< -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 09 May 2007 11:21, Randall R Schulz wrote:

I like the "System Monitor" panel applet available in KDE. To activate it (if you use KDE), right click in the panel and select "Add Applet to Panel..." and select "System Monitor." This applet shows three columns, CPU use, RAM use and Swap use. The first two show color-coded categories of resource utilization. For CPU it's kernel, user, nice, and I/O wait and for RAM, kernel, application, buffer and cache. You can customize the colors. 'ey thanks! You know, as much playing with kde as I do--- and I missed that one... very nice. I notice that right clicking on the colored bars gives me a configuration menu--- and hovering over the panel applet with the mouse also provides a real-time text update as well. heh.. I just pegged the cpu bars by grabbing the top of my mail editor and moving it around the screen a bit... isn't it just amazing that most of the time linux just sits there idle waiting to be almost 100% useful? Its got it all... fabulous resource management... and its fun too. I'm tempted to launch into a joyful hyperbole, but I spare y'all...

-- Kind regards, M Harris <>< -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Thank you to all for all the information. With respect to altering the O/S Memory Management - I really cannot justify literally playing with an aspect of the O/S that requires a CPU to work out. At different stages in my working life I have to learn or understand the memory management from Main Frame O/S such as TFP/DB/UG to Netware to a very ugly M$ and now Linux. All you contributions have answered all my needs for understanding of the Linux O/S with respect to memory management - and I cannot forget its origin evolution/derivation from Zenix/Unix/Linux. In return I offer you an article I wrote for Techrepublic.com on M$ poor excuse for relying (in my opinion) far too heavily on swap files which it does poorly.It also touches on its horrific direct memory addressing, but does leave out file cacheing. Although the intended audience for the article was "technical per say" I was asked to re-write it several times and make the section on M$ Memory that is directly accessible by the poor old O/S I am now so very grateful I now use Linux, for many many reasons. Again Thanks to all Scott and good night 05:18 GMT +10 Quote The Good, the Bad and the poor overwork I/O subsystem Using the Hard Disk to simulate RAM, which is a long standing feature of Main Frame operating systems certainly has its advantages but ultimately will degrade performance. Having an application use virtual RAM means that there must be an increase in Disk I/O. The advantage is that the application will run and not run out of RAM but there is a balance. Firstly an application must perform a disk I/O to receive the program files in limited pieces and the more physical RAM the greater the amount of information that can be read from the Disk. (Theoretically) Now IF some of that RAM is a page file on the hard disk another Disk I/O is required to access the page file RAM. If the disk is already busy reading application files and now we increase its load by pagefile also creating a disk I/O there must be a point were the disk and O/S needs to decide which is more important. The decisions are 1. The disk I/O to read the application program files 2. The disk I/O to write back and simulate RAM to run the same application just read from Disk. Effectively, as you don't get anything for nothing, the dilemma is "Are the Disk I/O's more busy reading the application program files than it is writing a disk I/O to simulate the RAM required to run the very same program. The problem that we face is always the amount of RAM that an application can directly access to process instructions - this is a constraint of the O/S. Just because you have 4 GIG of RAM does not mean that the O/S can directly address all 4 GIG. Quite the contrary. This is where our memory managers come into play. Lets say the O/S can only directly address the first 640K of RAM. What the memory manager does is load instructions into the registers of the 640K RAM - process those instructions and the memory manager then throws the result up into the rest of the RAM. When the result is needed again, to further process, it is dragged out of the upper RAM back down to conventional RAM and further processing can occur. A memory manager that allows the whole amount of RAM to be used is just like a juggler throwing thing up and fetching them back when needed. With the added facet of the pagefile once the physical RAM becomes full a Disk I/O is required. At some stage the O/S needs to make a decision. Is it better to devote more Disk I/O time to reading instructions OR does it utilise time to write an I/O to the page file. This is all managed by the O/S. Personally IF the PC has the max amount of physical RAM installed AND still requires a Disk I/O to simulate more RAM then we really need to think about the fundamental operation of the O/S. How much RAM can it directly address and how much RAM does it need to juggle in and then does it requires a page file as well - Personally then its time to re-write the O/S in its memory management and its directly addressable RAM to process and the amount of physical RAM used by the memory manager. Page file addressing should be a last resort by the O/S. Adding to an overworked disk I/O will slow things down ultimately, however the application will never fall over and you will never see the old "out of memory" error response which is the only advantage of such an arrangement. If you have multiple hard disks the best thing you can do is direct the temp variable (another story) and place the page file on a different disk than the disk containing the O/S. This will help the overworked disk I/O of the single disk but don't get excited yet – we then run into the bottle neck that is the I/O Bus speed which has nothing to do with the speed of the processor nor the speed of the RAM. Thank GOD for a 64 bit BUS. Next time you purchase a PC – just compare the BUS speed as this will ultimately constrain the total amount of I/O weather they come from the Disk array, the processor and the RAM – this is of particular importance, together with the speed of the Disk I/O when we start to employ a page file to speed up? the PC. Unquote. Randall R Schulz wrote:

On Monday 07 May 2007 18:16, Carlos E. R. wrote:

...

The Monday 2007-05-07 at 07:25 +1000, Registration Account wrote:

...

...

For example I have 2 GIG of RAM currently and am thinking of changing it to 4 GIG. I understand that the kernel can use more file cacheing, but that is what I do not want to know. With the superior way the Linux Kernel manages Memory, if we remove the increased file caching ability will the Kernel be able to utilise the extra memory registers for processing.

I think you got it wrong... if there is more memory, programs will be able to use more memory, /if/ they request it. All unused memory will simply end up being used as cache.

If currently, with 2G, you see no swap used, increasing the ram will not give more memory to programs.

This is true, as far as it goes. However, the kernel makes good use of physical memory pages not currently needed by applications. It uses them to cache disk contents and reduce the amount of physical disk I/O required to satisfy any given set of file system requests.

So even if your application mix never needs more than, say, 1GB, having 2GB or 4GB (or any larger amount, as long as your hardware is such that it's actually accessible, which depends in large part on the CPU you're using--modern systems can all typically access at least 2 or 3GB), having more than that much physical RAM can still improve your system's overall throughput.

...

-- Cheers, Carlos E. R.

Randall Schulz

As I stated the article I was asked to write was on MS Windows O/S and has not the slightest thing to do with Linux and I expressed my joy of not having to deal with it any more. Scott M Harris wrote:

On Wednesday 09 May 2007 14:20, Registration Account wrote:

...

Personally IF the PC has the max amount of physical RAM installed AND still requires a Disk I/O to simulate more RAM then we really need to think about the fundamental operation of the O/S. How much RAM can it directly address and how much RAM does it need to juggle in and then does it requires a page file as well - Personally then its time to re-write the O/S in its memory management and its directly addressable RAM to process and the amount of physical RAM used by the memory manager.

The above paragraph is an over simplification, and not entirely correct in general, and not correct at all in terms of Linux. There are legitimate uses for a swap file... and many linux installations make use of several large swap files on each machine! My current desk machine has a swap file of 1024M and real ram of 512M. I will generally set my swap file to twice the size of main store--- but there is no such fixed rule. Having said that--- most of the time my machine *never* swaps. I've been watching my new system monitor (thanks Randall) now most of the afternoon and my machine has not swapped... not once. As I have used the machine (mostly mail, small compiles, web research) I have noticed the kernel adjusting my cache and buffer sizes and moving along quite happily. This in contrast to my old W2000 and NT machines that would constantly *thrash* after moderate use... this means many page faults and lots of wasteful disk I/O like you talk about in your article. The windoze platform has lousy memory management and even worse file system management. The Linux kernel has *none* of these problems. This is no exaggeration--- memory management on Linux is comparable to memory management on MVS/XA, VM, SysV, Sys38, AS400, name it... seriously.

...

Page file addressing should be a last resort by the O/S. Adding to an overworked disk I/O will slow things down ultimately, however the application will never fall over and you will never see the old "out of memory" error response which is the only advantage of such an arrangement.

(see above) Paging is used by the Linux kernel on a needs basis-- absolutely. And, sometimes those needs are very real and quite legitimate. The more you play around with the Linux kernel the more comfortable you will become of course, but rest assured--- you're in good hands. Its easy to create stress scenarios for your machine that will tax memory and force paging... check it out.