- scheduler: add example code for SETI@home's situation

where app has both GPU and CPU versions,
    but for certain jobs (VLAR WUs in this case)
    the GPU version performs poorly and shouldn't be used.

    The fix is a kludge - it will result in these jobs
    not being sent to the host at all,
    rather than being sent with the CPU app.
    The current architecture makes it difficult to do otherwise.
    One possible fix would be to create a separate app
    for VLAR jobs, with only CPU app versions.


svn path=/trunk/boinc/; revision=20419
This commit is contained in:
David Anderson 2010-02-04 17:34:55 +00:00
parent 5f1bf70056
commit 84701e3624
2 changed files with 27 additions and 0 deletions

View File

@ -892,3 +892,19 @@ David 4 Feb 2010
user.inc
user/
home.php
David 4 Feb 2010
- scheduler: add example code for SETI@home's situation
where app has both GPU and CPU versions,
but for certain jobs (VLAR WUs in this case)
the GPU version performs poorly and shouldn't be used.
The fix is a kludge - it will result in these jobs
not being sent to the host at all,
rather than being sent with the CPU app.
The current architecture makes it difficult to do otherwise.
One possible fix would be to create a separate app
for VLAR jobs, with only CPU app versions.
sched/
sched_customize.cpp

View File

@ -54,6 +54,17 @@
#include "sched_customize.h"
bool wu_is_infeasible_custom(WORKUNIT& wu, APP& app, BEST_APP_VERSION& bav) {
#if 0
// example: if WU name contains "_v1", don't use CUDA app
// Note: this is slightly suboptimal.
// If the host is able to accept both GPU and CPU jobs,
// we'll skip this job rather than send it for the CPU.
// Fixing this would require a big architectural change.
//
if (strstr(wu.name, "_v1") && bav.host_usage.ncudas) {
return true;
}
#endif
#if 0
// example: for CUDA app, wu.batch is the minimum number of processors.
// Don't send if #procs is less than this.