Richard Haselgrove wrote:
>
> David, we need to test this one (thanks for listening, BTW) to make
> absolutely sure that the active (running) task set on return from
> benchmark is always identical to the set preempted - otherwise we get
> the memory over-allocation that John has reminded us of.
I'm pretty sure this is the case.
The logic in CLIENT_STATE::poll_slow_events() is
1) check whether to benchmark
2) check whether to suspend all jobs;
suspend or resume all jobs accordingly.
3) do CPU scheduling stuff, but not if all jobs suspended
So when benchmarks are finished,
all jobs that were previously running will be resumed in 2).
It's possible that some of them will immediately be preempted
in 3), but in that case the GPU jobs will be removed from memory.
However: we should definitely test this as much as possible.
-- DPA
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
