ram, swap, and Multi-Directional Gravitational Wave search on O3

chilina
chilina
Joined: 27 Sep 14
Posts: 22
Credit: 29109314
RAC: 33607

OK so just a quick follow-up,

OK so just a quick follow-up, just in case anyone searches the forum for this topic.

My m1 Mac mini can run 2 of the O3MD1 projects, plus 1 other non-O3MD1 project, without overloading the ram and using lots of swap.  I've added the app_config.xml file as above (but with a max of 2 projects), and I typed it into a text file as copy/paste didn't quite do the trick.  And then I've set my Computing Preferences to use 38% of the CPU cores (so 3 of the 4 performance cores), and to use 67% of the CPU time (which could probably go a bit higher).

It's great to be able to run these projects again without overloading the ram.  Thanks so much to those that posted all the helpful comments!

Scrooge McDuck
Scrooge McDuck
Joined: 2 May 07
Posts: 1077
Credit: 18261106
RAC: 12776

a corresponding

a corresponding observation:

O3MD1 CPU tasks usually allocate ~2 GiB RAM directly after task start. But are the full 2 GiB actually being actively used? I'm not sure. If you suspend such task (in BOINC's manager) and then send the computer (example: Windows) into hibernate mode (Suspend to Disk), it seems that the task's memory set is first swapped out from RAM to the swap file and finally the remaining used system memory is written to the hibernate file. If you now wake up the computer from hibernate mode (reading from hibernate file), the O3MD1 task (process, PID) is still there (as assumed) and now only occupies approx. 3 MiB in RAM. So the task's allocated memory still resides almost completely in the swap file (as assumed). If I now resume the previously suspended O3MD1 task in the BOINC manager again, the swapped out memory set is loaded back into the active working set in RAM (within one sub-routine of the O3MD1 task: a single progress dot "." in stderr.txt) from swap file.

BUT: ONLY 1.3 GiB of 2 GiB task's swap size is loaded back as active working set, not the initially allocated 2 GiB. During the further processing of the O3MD1 CPU task, the active memory set remains stable at 1.3 GiB. The computer also doesn't reload further memory pages from swap: the total number of page faults isn't increasing. So it stays at 1.3 GiB of active working set size until the task sucessfully finishes.

I don't have an obvious explanation for this behaviour. Maybe some inefficient (non-necessary) memory allocation? Anyway, it's no bug or problem, but a feature: O3MD1 CPU tasks consume lots of memory.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.