Hi

I have a laptop with 1GB physical memory and 2GB virtual memory.

I have firefox, several xterms, amarok and more running at a time. When i run the top or the free command it doesnt show anything about the system using any virtual memory, its says "0k used" at the swap space line and the number 0 at the swap line when using the free command.

When i read the top manual page is see that the "VIRT" column is used to display the virtual memory the process is using and when i check the VIRT column it shows 404m in one column and more in another column, yet the top program doesnt display any virtual memory as used.

Can someone please explain whats going on here, i mean, why isnt top or free displaying the amount of virtual memory used ..they just display 0k virtual memory used...

Maybe that is enough that your system doesn't want to use any swap. Or maybe something is wrong. You haven't given enough info.

That is meaningless. So what did you think that means? Why do you think you have 2GB virtual memory?

VIRT includes several kinds of memory that are neither in physical memory nor in the swap space. So a large number in VIRT doesn't necessarily mean a large amount of physical ram or swap is being used.

Do you mean "more in another row"? Otherwise, what you said doesn't seem to mean anything.

Only with more information.

It's always good to provide the output from these commands as something for us to refer to. Use code tags around the outputs from: 'free -m' and 'top -b -n 1 | head -15'

okey. thanks for your answers.

Here is the output from free -m:
Now it seems like almost all available physical RAM is used, but not enough to use swap. Usually there is only 16MB left and it seems to stay at that amount of physical RAM no matter how many other programs im starting.

Output from top:
And from the top manual page:
It says the total amount of virtual memory used.. when it says "all code, data and shared libraries".. would that mean all the virtual memory used to store code, data and shared libraries?

Please tell me if you need more information and if so then what kind.

Notice most of the memory is used by file caching, not by ordinary process memory (686 file caching, 315 ordinary memory use).
I don't know how to get a meaningful breakdown of an individual process's virtual memory usage (much less the whole system). But you can see that the two processes you listed have VIRT far in excess of even the sum of RES and SHR. That combined with the lack of use of swap area leaves two possibilities that I know of:

1) Almost all their virtual memory use is "demand zero" memory, meaning the internal memory manager (malloc or equivalent) in the process has allocated virtual address space from the kernel, but hasn't actually used it.

2) Memory mapping large data files but not accessing them.

Either way, for most practical purposes that virtual memory use isn't real.

As you start other programs, the system uses less memory for file caching and more memory for those processes and doesn't swap anything. That means one of two things:

1) You have a lot of very old data in the file caching memory, so the basic LRU rules cause file caching to be reduced instead of stale process memory.

2) You have swappiness set very low.

True, but only because the definition of "SWAP" is VIRT minus RES. "SWAP" does not tell you how much swap space is in use.

It means all virtual address space used for code, data (including "demand zero" that takes no space in physical ram nor swap and non sharable file mappings, that might take no space in ram and anyway takes none in swap) and shared libraries (and other shared mappings, that also might not take space in ram, yet still never take space in swap).

Here is the output from that command:

I was editing the above into my post while you gave the answer about swappiness. You have the default swappiness. So that eliminates one of those two meanings, leaving only the meaning that you have a lot of very old data in file caching that the kernel discards whenever it needs memory.

Good isn't it ?.
That's the way it's designed - the user (you ) doesn't have to worry about it because memory management in the kernel does.
Usually stated as "you paid for all the memory, why not use it all". Buffers and (disk/page) cache are used to fill the "unused" memory and released as programs demands more storage. This is the line you should be concentrating on - it adjusts for cache/buffer usage.BTW you seem to be confusing the use of "virtual". In one context you use it to mean "swap space", and in another you quote the definition from top of "VIRT". Whilst not incorrect, it pays to keep them separate - especially in the one post ...

Maybe.

Probably, but I think you'll agree this is unusual. There are 104 sleeping tasks. Usually the kernel will decide some pages used by the tasks that have been sleeping longest are so stale that it is better to swap them out than reduce the file caching. In this case that hasn't happened.

That certainly answers the main question here. But it brings up that more subtle secondary question. Why does the kernel continue to think the most stale pages in sleeping tasks are less stale than the most stale pages in the file cache? This hints that the file cache still contains some files that were used only once at boot up, which would imply the total of all files ever read since the completion of boot up is less than the 600m in file cache. That's a pretty lightly used system. If this system has read more files than that, then something isn't working as designed.

I've noticed a number of these odd memory posts lately. (Just info for thought.)

I don't know about this. I've got 140 sleeping tasks on my Lenny machine at the moment, and no used swap. (Swappiness is also 60)
Don't know if this contributes to the discussion or not, but just thought I'd throw it in.

But if I'm reading that right, you also have 4GB of physical ram with both tiny use of ram by processes and tiny use of ram by file caching. So obviously your system shouldn't be swapping stale pages out of sleeping processes. It isn't even dropping stale pages out of file cache. You never read enough files to even fill the file cache.

The is easier to understand than repeatedly dropping stale pages from file cache without ever swapping stale pages from sleeping tasks.

I don't see why you think that.
Swapping is slow, and expensive - by definition you have to swap out, then (potentially) also swap back in at sometime. Swap is also only used for dirty anonymous pages - i.e. those malloc'd and actually used by the process. On the other hand, unchanged (disk) cached pages are already on disk (by definition), so they never need to be written back - they are simply dropped from the active q and reused elsewhere.
Note that all (any) of this is only done if there is pressure on memory - it's too expensive to continually run the page q's moving pages back and forth. This is a lazy deallocation - pages may appear still allocated to defunct tasks, but will normally only be moved to the free q if needed.

Hi, What could we use to benchmark this?

Do any of you have a suit of programs or app you use to stress test

a Linux system?

Cheers Glenn

<edit>
OK, I know a few stand alone, like memtest86+, But I'm thinking of gui mode many tasks at once.
</edit>

Not a benchmark tool, but to tax a system - the aptly named Stress Tool

I don't think your question is related enough to tack onto the end of this old thread. You should have started a new thread.

Of course in a new thread you couldn't just use the word "this" that way and expect people to understand. You would need to specify what you mean.

However, the same is true even tacked on an old thread. Your use of the word "this" doesn't quite work. "this" must be something related to the topic discussed in the thread above. I can think of several things in this thread "this" might refer to that someone might want to benchmark. No one of those stands out as the most likely meaning.