Memory scheduling

[MikeMarsUK]

Hi,

I prefer to 'keep in memory' whenever possible, but a couple of times Boinc has run into a deadlock situation. It starts a SAP task (450MB peak) when the PC is idle, but then the PC becomes busy, and the task is suspended due to lack of memory (due to the idle memory limit being higher than busy limit).

However, rather than just waiting, or starting a low-memory task, it starts another SAP task. This takes up another 450MB, and as a result there is too much in memory for both the idle and busy limits, and the Boinc manager is stuck.

A related problem is that on dual core boxes, the scheduler allows two tasks from the same project to start at similar times even when the STD is only marginally in favour of that project. This loads unnecessary items into memory (i.e., two WUs for each project), when a slightly more cautious scheduler would be able to satisfy STD with only one task.

Could I therefore make a few suggestions:

• When Boinc reaches a 'waiting for memory' state on one task, it shouldn't start another high-memory task.

• If one of the tasks has been recently checkpointed, and boinc is in a 'waiting for memory' state, it should remove it from memory even if the 'keep in memory' flag has been set to Yes.

• The scheduler should be reluctant to load new tasks into memory if there is a task already in memory which can be run instead. Perhaps if STD is less than the timestep interval for a project, and it already has a task running, the scheduler should continue running an in-memory task from another project instead.

The memory deadlock issue was with version 5.8.16 of the Boinc manager, and the two-tasks-for-each-project issue was with version 5.10.6. If these have already been resolved in the current head version then please feel free to close this Trac item.

[Nicolas]

Fixed list on description.

[Nicolas]

Can anybody reproduce this on recent versions?

Marking as major because that memory mess makes the computer slow for the user.

[icode4u]

I can confirm this was a problem with v6.4.5. I tested using Rosetta@Home in a two CPU virtual machine (Ubuntu 32-bit) using BOINC client 6.10.17. It appears this problem has been fixed. BOINC did start one additional task, but it forced unloading of the program once memory limits were exceeded.

A senior developer should verify and sign off on this.