Ticket #305 (new Enhancement)

Opened 2 years ago

Last modified 3 months ago

Memory scheduling

Reported by: MikeMarsUK Assigned to: davea
Priority: Major Milestone: Undetermined
Component: Client - Scheduler Policy Version:
Keywords: memory suspend resume deadlock Cc:

Description (Last modified by Nicolas)

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.

Change History

07/02/07 17:49:37 changed by Nicolas

  • keywords changed from memory suspend resume keep-in-memory waiting-for-memory deadlock to memory suspend resume deadlock.
  • description changed.

Fixed list on description.

07/03/07 05:13:09 changed by KSMarksPsych

  • priority changed from Undetermined to Minor.

09/07/07 14:42:13 changed by Nicolas

  • priority changed from Minor to Major.

Can anybody reproduce this on recent versions?

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


If this page is incomplete or incorrect, please edit it or add it to the wiki to-do list. To do this, you must be logged in; click Login or Register above.