memory not released after running program

Hi,
I am programming in Emacs and Ubuntu8.10.

I have finished running my C++ program from Emacs, even exited Emacs, however the memory used by my program is still held by the system. System monitor shows this in the memory and swap charts under "Resources" tab, but does not show the process that takes that large amount of memory in its "Processes" tab, so I have no clue how to release the memory. Is there a bash command that can release memory? Also even if there is no deallocation of memory in the code, why after the program finishes its running it does not release the memory used?

Thanks and regards!

You are misinterpreting something. Either your program is actually still running, or you are looking at the buffer/cache usage, which is meaningless for measuring actual memory pressure.

How to measure the actual memory pressure? In Ubuntu's system monitor, does the two circular charts, one for memory and one for swap, not measure the actual memory pressure? The result shown in system monitor is:

Quote:

Memory
471.0 MiB (49.8%) of 944.9 Mib
Swap
269.1 MiB (27.4%) of 949.1 MiB

However it is different from the result by top:

Quote:

Mem: 967588k total, 788012k used, 179576k free, 11320k buffers
Swap: 971892k total, 266308k used, 705584k free, 303604k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6381 root 20 0 162m 81m 8200 R 18.8 8.6 190:45.85 Xorg
23322 ting 20 0 43472 20m 11m R 15.5 2.2 32:15.48 gnome-system-mo
3338 ting 20 0 260m 102m 30m S 2.3 10.8 7:13.74 firefox
14391 ting 20 0 208m 48m 22m S 2.0 5.1 0:42.75 python
24781 ting 20 0 111m 25m 13m R 2.0 2.8 0:30.38 gnome-terminal
15756 ting 20 0 2416 1148 876 R 0.7 0.1 0:06.62 top
20538 ting 20 0 5280 1696 1364 S 0.7 0.2 0:04.76 wget
2603 root 15 -5 0 0 0 S 0.3 0.0 1:41.31 b43
6801 ting 20 0 21344 4820 4156 S 0.3 0.5 6:50.97 gnome-screensav
6852 ting 20 0 54800 15m 9284 S 0.3 1.6 1:51.14 nm-applet
1 root 20 0 3056 516 460 S 0.0 0.1 0:01.94 init
2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
4 root 15 -5 0 0 0 S 0.0 0.0 0:17.66 ksoftirqd/0
5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
6 root 15 -5 0 0 0 S 0.0 0.0 0:03.52 events/0
7 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khelper

BTW, I cannot find my process in the output of top or system monitor.

If you look at the output of top, you'll notice that if you take "788012k used" from the first line, then subtract the "11320k buffers" from the first line and also subtract the "303604k cached" from the second line, you get 473088, which is extremely close to the number that Ubuntu is reporting.

So I do believe the ~470 megabyte number. I was worried that you were looking at top's "179576k free" statistic, which is misleading and not a true indication of available RAM.

Quote:

BTW, I cannot find my process in the output of top or system monitor.

Then it's not running, and it's impossible for it to be taking up usable memory, unless your program is doing something like allocating a SysV shared memory segment and then forgetting to deallocate it before exiting.

Thanks, brewbuck!

Will "new" allocate a SysV shared memory segment? "new" is the only function I used to allocate memory. What is "allocating a SysV shared memory segment" like?

The OS seems unable to deallocate the memory. Is there some way to do that without restarting OS?

Quote:

Originally Posted by brewbuck

Then it's not running, and it's impossible for it to be taking up usable memory, unless your program is doing something like allocating a SysV shared memory segment and then forgetting to deallocate it before exiting.

Quote:

Will "new" allocate a SysV shared memory segment?

No, it will allocate memory off the application's heap.

So the OS still can handle the deallocation even if I forgot to call delete.

What else could possibly cause the memory being held? Does it have something to do with the fact that I run the C++ program from Emacs sometimes within GDB ?

Anyway to release the memory?

How can I release the cached part in swap and buffer part in Memory?

There is a way to clear the cached memory, but I'm not going to bother looking up how to do it. I can't think of a valid reason why someone would ever want to do this.

I'm willing to bet that the OS is not holding any of the application's memory after it exits. If your process is not on "top", then it is not using any memory.

Quote:

Originally Posted by lehe

So the OS still can handle the deallocation even if I forgot to call delete.

What else could possibly cause the memory being held? Does it have something to do with the fact that I run the C++ program from Emacs sometimes within GDB ?

Anyway to release the memory?

How can I release the cached part in swap and buffer part in Memory?

Are you actually seeing a problem, or are you simply trying to make sense out of some numbers that you do not understand.

You must understand that OS's do a lot of work "under the covers" and use free memory as cache for various purpose. When you first run your application, shared libraries may be loaded for the first time. If there is plenty of free memory (e.g. you have 1GB and only run a basic Linux setup), the OS will not remove the shared libraries from memory just because the application exits.

Likewise, if your application reads from files (including loading shared libraries and other such things), the file-system data that the OS uses to find the files needed will be loaded into memory, and some or all of the file-content as well. Again, if there is plenty of free memory, why should the OS "throw away" that data, when there is nothing else that requires that memory to be used?

If you are running an ordinary standard distribution of Linux, I guarantee that unless your program does really unusual things, the memory it uses will be available to be used.

Caches and such are flushed when the OS needs to use that memory (e.g. if you load a 400MB file into Emacs). But if there is nothing else needing the memory, it remains in use as cache - it will not serve a better purpose just sitting empty, right?

--
Mats

Thanks!
Even after I exit Emacs from where I run my program, the percentage of used memory does not change. Can we say the memory it uses will be available to be used?

Quote:

Originally Posted by lehe

Thanks!
Even after I exit Emacs from where I run my program, the percentage of used memory does not change. Can we say the memory it uses will be available to be used?

Unless you are running into problems where starting emacs again (for the umpteenth time, perhaps), yes, I'd say so. Programs only take up memory when they are in use, but the OS doesn't like "free" memory, so it tries to fill all of the memory with something that makes sense. Caching the file-system is one such thing, leaving shared libraries loaded after the app exits is another example. There are probably other things too that are cached, but those are the obvious ones.

Free memory is of no use (unless you have applications that need a lot of memory, but even then caches can be disposed of, especially those that do not need writing to disk first).

--
Mats

We have to make a distinction between "unused" memory and "available" memory. As matsp said, the OS tries to completely fill memory with data in a way that will improve system performance. For instance, by caching filesystem blocks. This memory is "in use," but it is also "available" because if an application demands memory, the OS can simply discard the cached data and turn the memory over to the application.

It's notoriously difficult to define how much free memory exists on a system. In my mind, memory is "free" if it can be immediately assigned to an application without needing to copy its contents to backing store. In other words, shared memory pages which are not currently mapped to any process, and are not dirty, are fair game. File system buffers which aren't dirty are fair game. Everything else needs to either be written back to the filesystem or to swap before the OS can hand over the pages to an application.

Quote:

Originally Posted by bithub

There is a way to clear the cached memory, but I'm not going to bother looking up how to do it. I can't think of a valid reason why someone would ever want to do this.

I'm willing to bet that the OS is not holding any of the application's memory after it exits. If your process is not on "top", then it is not using any memory.

In fact, there is no way to dump the cache (in Linux). The kernel will dump each cache for each device AFTER it is unmounted, however, there is currently no system call that allow a user-space app to clear the system cache. -- I had this problem in an embedded system one time and had to do some really fancy footwork to get a tar command to work properly twice (c then x). Had to umount the FS several times as it was a large data store.

Quote:

In fact, there is no way to dump the cache (in Linux). The kernel will dump each cache for each device AFTER it is unmounted, however, there is currently no system call that allow a user-space app to clear the system cache. -- I had this problem in an embedded system one time and had to do some really fancy footwork to get a tar command to work properly twice (c then x). Had to umount the FS several times as it was a large data store.

There definitely is a way to dump the cache. It's not a system call, you have to echo something into a /proc. I can look it up if needed (or ask someone at work that knows how to do this). We messed around with it for a little while when we were having cache problems on one of our products.

Quote:

Originally Posted by Kennedy

In fact, there is no way to dump the cache (in Linux). The kernel will dump each cache for each device AFTER it is unmounted, however, there is currently no system call that allow a user-space app to clear the system cache. -- I had this problem in an embedded system one time and had to do some really fancy footwork to get a tar command to work properly twice (c then x). Had to umount the FS several times as it was a large data store.

One way to clear the cache is to run this:

Code:

/* eat_all_memory.c */ #include <stdlib.h> int main() { char *page; while( page = malloc( 4096 ) ) *page = 1; return 0; }

Looks sucky, but is portable to pretty much any OS you want ;)

That won't work if you are using a 32 bit OS that has more than 3GB of RAM :)

At any rate, I think this is the command to flush the system cache:

Code:

echo 3 > /proc/sys/vm/drop_caches

bithub: That does NOT clear the FS cache from the kernel memory. What happens is the memory is marked as "freed" but the kernel does not actually drop those pages until (1) a write of the file occurs -- In this case you only have a new copy of the same file in memory, the original read() file is dropped or (2) if you umount the file system. If you don't believe me, look around in the code. I found this problem about two years ago. . . I asked the maintainers of the code why and they said "because." <-- This is not a joke.

As far as eating memory goes, that doesn't work either. The problem I was having was that tar couldn't get enough memory since the KERNEL had that memory for cache. Kernel memory overrides user memory, thus tar would not function properly.

The Linux Kernel maintainers say that in "normal operating conditions" the kernel will release the cache after a period of time. My problem was that I was chewing all 64MB of my memory by off-loading ~2GB of data to a 4GB jump drive so that I could reconfigure my CF device (on-the-fly without user intervention). After the initial read of the data I had to unmount and remount to get the sucker to behave properly. Likewise, after the write I had to unmount again. I tried _EVERYTHING_ to get it to do it any other way, but the only success I had was to umount the filesystems (both the CF and the USB memory stick). (BTW, the original filesystem on the CF was ext3 mounted with noatime -- This would hang at boot sometimes, which in an embedded system is terrible, so we changed it to Reiserfs to fix the problem.)

Quote:

bithub: That does NOT clear the FS cache from the kernel memory.

So you're saying that even though every memory diagnostic utility will show that the memory has moved from "cached" to "free", the memory has not actually been released from the cache? I disagree with this. Now the above command will not free "dirty" cache pages. To get around this you can tell the kernel to write out dirty cache pages to disk using the "sync" command. Also, if the drop_caches proc didn't work, I would have expected Andrew Morton to say as much in this bug.

Quote:

The problem I was having was that tar couldn't get enough memory since the KERNEL had that memory for cache. Kernel memory overrides user memory, thus tar would not function properly.

The kernel should release cached memory to the application if the application attempts to allocate more memory than what is "free" on the system. I don't see how the system cache can "override" user memory, that's not how the Linux kernel works (Unless I have been misinformed all these years, which is possible).

Quote:

My problem was that I was chewing all 64MB of my memory by off-loading ~2GB of data to a 4GB jump drive so that I could reconfigure my CF device (on-the-fly without user intervention). After the initial read of the data I had to unmount and remount to get the sucker to behave properly.

You could have written the 2GB using O_DIRECT. This would bypass the system cache entirely. Of course I'm not convinced that the cache was the root of your problem (see my above comment regarding the kernel freeing cache memory when an application requests more). Then again, I've been wrong before, so take this with a grain of salt :)

Quote:

Originally Posted by Linus Torvalds

The right way to do it is to just not use O_DIRECT.

The whole notion of "direct IO" is totally braindamaged. Just say no.

This is your brain: O
This is your brain on O_DIRECT: .

Any questions?

I should have fought back harder. There really is no valid reason for EVER
using O_DIRECT. You need a buffer whatever IO you do, and it might as well
be the page cache. There are better ways to control the page cache than
play games and think that a page cache isn't necessary.

So don't use O_DIRECT. Use things like madvise() and posix_fadvise()
instead.

Linus

Quote:

Originally Posted by bithub

So you're saying that even though every memory diagnostic utility will show that the memory has moved from "cached" to "free", the memory has not actually been released from the cache? I disagree with this. Now the above command will not free "dirty" cache pages. To get around this you can tell the kernel to write out dirty cache pages to disk using the "sync" command. Also, if the drop_caches proc didn't work, I would have expected Andrew Morton to say as much in this bug.

Through 2.6.18 (at a minimum) Yes. Check out the LKML about it. I cannot remember if that is where I made my stink (Don't have those e-mails anymore -- another job). . . But writing 3 to drop_caches didn't work -- PERIOD. So, if you want to you can disagree -- you're still wrong.

The fact that Linus doesn't like O_DIRECT has nothing to do with whether it works or not. I agree with him 100% that you should never need to bypass the page cache. You were the one that was stating that the page cache was limiting your application memory, not me... remember?

Quote:

So, if you want to you can disagree -- you're still wrong.

I did a search on the LKML, and there are a ton of messages about drop_caches. None of those messages say anything about drop_caches not actually dropping cached pages. Can you point us to a single resource at all which backs up your assertion that drop_caches doesn't work? I'm not saying you're wrong, I just find it suspicious that there's no posts that I can find to back up your claims.

Anyways, since you seem to be so sure of yourself, I did a little checking. Setting the drop_caches proc will execute the following code:

fs/drop_caches.c

Code:

28void drop_pagecache(void) 29{ 30 struct super_block *sb; 31 32 spin_lock(&sb_lock); 33restart: 34 list_for_each_entry(sb, &super_blocks, s_list) { 35 sb->s_count++; 36 spin_unlock(&sb_lock); 37 down_read(&sb->s_umount); 38 if (sb->s_root) 39 drop_pagecache_sb(sb); 40 up_read(&sb->s_umount); 41 spin_lock(&sb_lock); 42 if (__put_super_and_need_restart(sb)) 43 goto restart; 44 } 45 spin_unlock(&sb_lock); 46}

Which calls the following:
/fs/drop_caches.c

Code:

15static void drop_pagecache_sb(struct super_block *sb) 16{ 17 struct inode *inode; 18 19 spin_lock(&inode_lock); 20 list_for_each_entry(inode, &sb->s_inodes, i_sb_list) { 21 if (inode->i_state & (I_FREEING|I_WILL_FREE)) 22 continue; 23 invalidate_inode_pages(inode->i_mapping); 24 } 25 spin_unlock(&inode_lock); 26}

Now invalidate_inode_pages() just calls invalidate_mapping_pages():
/mm/truncate.c

Code:

223unsigned long invalidate_mapping_pages(struct address_space *mapping, 224 pgoff_t start, pgoff_t end) 225{ 226 struct pagevec pvec; 227 pgoff_t next = start; 228 unsigned long ret = 0; 229 int i; 230 231 pagevec_init(&pvec, 0); 232 while (next <= end && 233 pagevec_lookup(&pvec, mapping, next, PAGEVEC_SIZE)) { 234 for (i = 0; i < pagevec_count(&pvec); i++) { 235 struct page *page = pvec.pages[i]; 236 pgoff_t index; 237 int lock_failed; 238 239 lock_failed = TestSetPageLocked(page); 240 241 /* 242 * We really shouldn't be looking at the ->index of an 243 * unlocked page. But we're not allowed to lock these 244 * pages. So we rely upon nobody altering the ->index 245 * of this (pinned-by-us) page. 246 */ 247 index = page->index; 248 if (index > next) 249 next = index; 250 next++; 251 if (lock_failed) 252 continue; 253 254 if (PageDirty(page) || PageWriteback(page)) 255 goto unlock; 256 if (page_mapped(page)) 257 goto unlock; 258 ret += invalidate_complete_page(mapping, page); 259unlock: 260 unlock_page(page); 261 if (next > end) 262 break; 263 } 264 pagevec_release(&pvec); 265 } 266 return ret; 267}

As you can see it will skip dirty pages and memory mapped pages. Well invalidate_complete_page() looks like:
/mm/truncate.c

Code:

61static int 62invalidate_complete_page(struct address_space *mapping, struct page *page) 63{ 64 if (page->mapping != mapping) 65 return 0; 66 67 if (PagePrivate(page) && !try_to_release_page(page, 0)) 68 return 0; 69 70 write_lock_irq(&mapping->tree_lock); 71 if (PageDirty(page)) 72 goto failed; 73 if (page_count(page) != 2) /* caller's ref + pagecache ref */ 74 goto failed; 75 76 BUG_ON(PagePrivate(page)); 77 __remove_from_page_cache(page); 78 write_unlock_irq(&mapping->tree_lock); 79 ClearPageUptodate(page); 80 page_cache_release(page); /* pagecache ref */ 81 return 1; 82failed: 83 write_unlock_irq(&mapping->tree_lock); 84 return 0; 85}

Hmm... the function __remove_from_page_cache() sounds like it may actually do something...
/mm/filemap.c

Code:

110/* 111 * Remove a page from the page cache and free it. Caller has to make 112 * sure the page is locked and that nobody else uses it - or that usage 113 * is safe. The caller must hold a write_lock on the mapping's tree_lock. 114 */ 115void __remove_from_page_cache(struct page *page) 116{ 117 struct address_space *mapping = page->mapping; 118 119 radix_tree_delete(&mapping->page_tree, page->index); 120 page->mapping = NULL; 121 mapping->nrpages--; 122 __dec_zone_page_state(page, NR_FILE_PAGES); 123}

Are you still sure that I'm wrong? By the way, all this code is from 2.6.18 which is the version you claim has the broken drop_caches implementation.

Quote:

Originally Posted by bithub

Are you still sure that I'm wrong? By the way, all this code is from 2.6.18 which is the version you claim has the broken drop_caches implementation.

Yes.

My problem System not releasing memory and Drop_cache file not their in LInux4.0

Quote:

Originally Posted by Kennedy

Through 2.6.18 (at a minimum) Yes. Check out the LKML about it. I cannot remember if that is where I made my stink (Don't have those e-mails anymore -- another job). . . But writing 3 to drop_caches didn't work -- PERIOD. So, if you want to you can disagree -- you're still wrong.

When i am using (sync; echo 3 > /proc/sys/vm/drop_caches) its working fine in Linux 5.0 onwards. But in 4.0 A.S version Drop_caches folder is not their . I am facing problem that system is not relesing memory.Please help me How to clear unwanted cache in Linux4.0 versions.

AVL