Virtual memory allocation

[sojourner]

I don't know if I should raise a separate bug report. I was about to raise one when I saw this report. After a game is finished and I return to the main menu, the virtual memory usage remains very high.

(64 bit ubuntu 11.04)
v3.5.1-GNUC: 40502 [64bit]-May 14 2011 17:00:41, SVN: [Rev: 2254], [STREFLOP]

At the main menu (after the intro), vm usage was 409 MB

vm usage immediately after the game loaded was about 1G and by the end of the game (with 7 different AI factions) was about 4G. AFter the game exited the usage was still about 4G (even after returning to the main menu).

With another game, I exited in the middle of it, with 2G consumed and even after I was back at the main menu, the vm usage was at about 2G. Is there some caching or is this a memory leak?

All virtual memory usage mentioned above is for megaglest alone, not the whole system.

[tomreyn]

Yes, you should have raised a separate bug report, as the Bug reporting and trouble shooting (how to) states.
I don't think what you are discussing is related to the other topic. Nor do I consider is to be a bug.

Virtual memory is assigned by the kernel 'as needed' based on a variety of factors, and yes, it is used for caching. Amongst other things, it allows you to have a rapid game startup after the game data was first loaded into memory. You will notice that you can start a second game much faster than the first one after starting MegaGlest. Memory leaks would increase the amount of actually allocated/reserved memory. If this is not the case then this is most likely not a bug.

That's unless the increased virtual memory assignment makes your system swap much with default swappiness. If you think there is a problem then please answer this:
* How much free RAM do you have before starting MegaGlest? Please post the output of this command: free -m
* How much RSZ and VSZ are assigned to the MegaGlest process after you finished your game and returned to the main menu? Please post the output of this command: ps u `pidof megaglest` (note that these are backticks as in `, not single quotes as in ' )

[softcoder]

Note that opengl and video drivers handle memory in strange ways. I discussed this issue in the opengl channel and found it nearly impossible to free some memery that the video driver cache (yes they sometimes make use of normal system ram for things like often used textures, they don't always keep thing in GPU ram).

[sojourner]

Here is the data you asked for:

Code: [Select]

before megaglest:
             total       used       free     shared    buffers     cached
Mem:          3818       2935        882          0        202       1971
-/+ buffers/cache:        761       3056
Swap:         9535         47       9488

at the megaglest main menu (before any game is played):
ps u `pidof megaglest`:
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
eye      11479 56.0  1.5 404788 61416 pts/1    Rl+  08:32   0:59 mk/linux/megaglest --ini-path=mk/linux/ --data-path=mk/linux/

few seconds after a game was started:
eye      11479 67.0 16.5 1145876 646704 pts/1  Rl+  08:32   4:02 mk/linux/megaglest --ini-path=mk/linux/ --data-path=mk/linux/

just before exiting the game:
eye      11479 79.8 36.6 1903320 1434148 pts/1 Rl+  08:32  15:32 mk/linux/megaglest --ini-path=mk/linux/ --data-path=mk/linux/

back at the main menu:
eye      11479 79.7 34.1 1813160 1335868 pts/1 Sl+  08:32  16:11 mk/linux/megaglest --ini-path=mk/linux/ --data-path=mk/linux/

few seconds into a new game (as soon as the game started after using reload last settings):
eye      11479 79.0 47.2 2296536 1846816 pts/1 Rl+  08:32  18:25 mk/linux/megaglest --ini-path=mk/linux/ --data-path=mk/linux/

just before exiting the second game:
eye      11479  121 63.7 2951896 2490756 pts/1 Rl+  08:32  85:12 mk/linux/megaglest --ini-path=mk/linux/ --data-path=mk/linux/

back at the main menu after second game:
eye      11479  121 63.6 2927272 2487820 pts/1 Sl+  08:32  86:15 mk/linux/megaglest --ini-path=mk/linux/ --data-path=mk/linux/



[tomreyn]

This looks fine to me. The kernel has 3 GB physical RAM (which are not requested by any other application) to play with and the game can make use of it so it does. The 2,5GB RAM is has actually allocated (RSZ) by the end of the second game is, I think, more than it should be, and the linear increase of memory allocation across these two games can be an indication for memory leaks. However note that the game never allocates more RAM than you have physically available and not allocated to other processes so this can be totally legitimate.

If you could drive up the memory allocation to a value higher than what free -m|awk '/^-\/\+ buffers\/cache:/ {print $4}' reports before you start the game (possibly by playing three games in a row and could demonstrate that swapping takes place to a considerable amount then I think this would be strong indication of leaking memory. So far, there is no such indication, though. And searching for memory leaks can be quite a resource killer, so if there should be any leaks but they are not too problematic - you can always just restart the game after you played the last large round, and that's what we actually recommend - investigating this may not be worth it before the merge takes place.

[sojourner]

Understood. Thanks.