memory isn't freed _AFTER_ P-1 stage 2?
 

Hello,

I've running two machines with mprime v25.9 x86_64 doing LLs.
One machine is a dualcore and the other one is a quadcore machine.
The dualcore machine has 3GiB of memory so I've allowed mprime to use up to 2.5GiB of memory. (The numbers for the quadcore machines are 2GiB / 1.5GiB.)
Because they are doing LL test they need usually ~100MiB (dualcore) to ~200MiB (quadcore).
Both machines recently got LL asignments where P-1 was needed. During stage 2 of P-1 the memory usage of mprime went up to 2.5/1.5GiB.

Up to here I think everything is fine. But after they have finished P-1 mprimes memory usage is still 2.5/1.5GiB for doing just 2/4 LL tests.

With mprime 24.14 x86 the memory was freed after P-1 but v25.9 seems to keep all the memory even if it isn't used.

I've noticed the same behavior on Linux 64bit mprime-25.9-build3

I _believe_ that the freeing was ok with version 25.8 (where I couldn't use more than 1536MB RAM) - but I'm not 100% sure.

[QUOTE=TheJudger;161832]Both machines recently got LL asignments where P-1 was needed. During stage 2 of P-1 the memory usage of mprime went up to 2.5/1.5GiB.

Up to here I think everything is fine. But after they have finished P-1 mprimes memory usage is still 2.5/1.5GiB for doing just 2/4 LL tests.[/QUOTE]I run Prime95 25.9.3 64 bits and do not experience that problem. I must add that for several reasons not relevant here, I launch a second Prime95 instance to do all P-1 work, so that instance has only one worker thread. Anyway, as soon as P-1 stage 2 finishes, memory usage goes down from up to 7,6 GB to below 100 MB.

Jacob

I've running some instances of mprime v25.9 x86_64 doing P-1, too.
These clients actually free the memory when stage 2 is finished and they start stage 1 on the next exponent.

What is different on this clients:
- they do P-1 instead of LL
- only one worker (one thread)

hi George,

can we have a comment on this one?
Thank you!

I've never been able to replicate it. It sounds like some users do not see this either using the same version.

Is it possible that linux tools are just reporting the high water mark? For example, say P-1 allocs 2GB on worker 1, P-1 allocs 2GB on worker 2, worker 3 allocs 20MB for LL. Workers 1 and 2 finish P-1 and switch to LL, leaving a 4GB "hole" in the virtual address space. Until worker 3 frees its memory linux might report 4+GB in use.

If you stop all workers, does it go back down to almost no memory in use?
If you restart after stopping does it go back up to 3 LL's worth of memory in use?

Hi!

I'm pretty sure that it wasn't a high memory mark.

I'm running "mprime -d" so I can't access the menu to start/stop workers (can I?). When I stop mprime and start it again the memory usages was as expected.

Maybe this is a hint:
I have just looked into the logs again (the output of mprime -d goes into a file):
I seems that I've increased the "Memory" variable before this happened. I did this via "echo Memory=xxxx > local.add". The quadcore did 3 LLs and one P-1 stage 1 at the time where I have increased the maxium memory while the dualcore did 2 LLs when I did it.

Hi,

it happened again. :(
Process is still running, let me know if you want some more informations.

I have the same problem, it's still running.
I attached gdb and generated a corefile (800MB).

I could upload it if helpful.

[quote=Prime95;168954]I've never been able to replicate it. It sounds like some users do not see this either using the same version.[/quote]George,

Might there be some connection with either

a) what ettl.martin found ([URL]http://mersenneforum.org/showpost.php?p=179753&postcount=120[/URL]

[URL]http://mersenneforum.org/showpost.php?p=180033&postcount=122[/URL]
) or

b) some other improperly initialized variable, with different initial contents on different users' systems, could cause a repeatable error for some users but not others even though version and parameters are the same?

I know this wouldn't be a permanent fix to your problem, but it may work since a fix is lacking (as George cannot replicate the issue). Why not restart the program once the LL test has begun? This might force the program to realize it does not need the amount of memory used in P-1 Stage 2. Just a thought.