| Are you a betting man?
phil On Nov 30, 2009, at 7:59 AM, Dan Gibson wrote: Javier,
Having made that same graph on a couple of occasions myself, I can say with some confidence that this is correct behavior, and not a leak.
The phenomenon you're observing is an artifact of how Ruby implements 'arbitrary' coherence. Whenever a memory block is accessed for the first time, a directory entry is allocated for that line, which will be used to track some state relating to this block (see your protocol's Directory_Entry). This happens in DirectoryMemory::lookup. These blocks are never reclaimed.
Therefore, Ruby's memory allocation can continue to grow until the target system has accessed every block in its available memory.
I see in your post that you are using an application with a fixed working set. After touching all of it, I would expect memory usage to plateau for the most part, except for other system activity, a behavior that I have seen myself -- it also seems to happen at about X=800M cycles in your graph. Bear in mind that even a 'controlled' application isn't the only thing running on a full-system simulator, and Ruby's memory will still grow, inexorably, due to system activity and interference from other processes.
However, just to cover all our bases, try running Ruby's tester. Ruby's tester limits the number of actually addresses used to a handful, so the memory footprint should be more stable. Even then, I wouldn't be surprised if you still saw some inflation due to stats gathering (e.g., some maps in Profiler.C).
Regards,
Dan
2009/11/30 Javi Merino <jmerino@xxxxxxxxxxxxx>
Hi, when we run long simulations using GEMS+Simics, we get a very big
memory footprint. The attached file shows the total memory used by GEMS
+Simics during the simulation of one iteration of IS.B. We used GEMS 2.1
with MOESI_CMP_token and the default configuration. The only parameter
we modified is the number of processors (8). It is ruby+opal, but when
we simulate without ruby, the memory used is more or less constant.
If we simulate two or three iterations of this application, the memory
used keeps increasing, even though the working set of the simulated
application is the same across iterations.
The memory controller also uses a lot of memory, but it allocates it at
the beginning of the simulation.
Do you have any idea on where is the memory leak? It would be great if
we could keep the memory used under control and all GEMS users could
benefit from that. Regards,
Javier Merino
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
--
http://www.cs.wisc.edu/~gibson [esc]:wq!
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
|
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}