Just caught my first benchmark with v6.10.43, and http://setiathome.berkeley.edu/result.php?resultid=1552657035 thanks you for it - saved at least 10% of computation time (5 minute task, would have needed ~30 seconds for full restart). Waiting on validation because of faulty wingman, but looks OK.
Not a full test of resumption yet, because there wasn't anything else around that BOINC might have been tempted to start, but a good first step. 24/03/2010 19:11:42 Running CPU benchmarks 24/03/2010 19:11:42 Suspending computation - running CPU benchmarks 24/03/2010 19:11:42 s...@home [cpu_sched] Preempting 29mr07ae.11840.23385.5.10.101_1 (left in memory) 24/03/2010 19:11:42 s...@home [cpu_sched] Preempting 29mr07ae.12130.3753.6.10.145_0 (left in memory) 24/03/2010 19:11:42 s...@home [cpu_sched] Preempting 11mr07ae.26119.188260.4.10.84_0 (left in memory) 24/03/2010 19:11:42 s...@home [cpu_sched] Preempting 11mr07ae.26119.189078.4.10.80_0 (left in memory) 24/03/2010 19:11:42 s...@home [cpu_sched] Preempting 09mr07ag.8624.1708.4.10.189_1 (left in memory) 24/03/2010 19:12:14 Benchmark results: 24/03/2010 19:12:14 Number of CPUs: 4 24/03/2010 19:12:14 2361 floating point MIPS (Whetstone) per CPU 24/03/2010 19:12:14 4791 integer MIPS (Dhrystone) per CPU 24/03/2010 19:12:15 Resuming computation 24/03/2010 19:12:15 s...@home [cpu_sched] Resuming 29mr07ae.11840.23385.5.10.101_1 24/03/2010 19:12:15 s...@home [cpu_sched] Resuming 29mr07ae.12130.3753.6.10.145_0 24/03/2010 19:12:15 s...@home [cpu_sched] Resuming 11mr07ae.26119.188260.4.10.84_0 24/03/2010 19:12:15 s...@home [cpu_sched] Resuming 11mr07ae.26119.189078.4.10.80_0 24/03/2010 19:12:15 s...@home [cpu_sched] Resuming 09mr07ag.8624.1708.4.10.189_1 24/03/2010 19:15:17 s...@home Computation for task 09mr07ag.8624.1708.4.10.189_1 finished 24/03/2010 19:15:17 s...@home Starting 28mr07ae.10809.4162.16.10.116_1 24/03/2010 19:15:17 s...@home [cpu_sched] Starting 28mr07ae.10809.4162.16.10.116_1 (initial) > 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.
