Rooba
/
boinc
mirror of https://github.com/BOINC/boinc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
boinc/client/app_config.h

65 lines
1.6 KiB
C
Raw Normal View History

- client: add "client app configuration" feature; see http://boinc.berkeley.edu/trac/wiki/ClientAppConfig This lets users do the following: 1) limit the number of concurrent jobs of a given app (e.g. for WCG apps that are I/O-intensive) 2) Specify the CPU and GPU usage parameters of GPU versions of a given app. Implementation notes: - max app concurrency is enforced in 2 places: 1) when building the initial job run list 2) when enforcing the final job run list Both are needed to avoid possible starvation. - however, we don't enforce it during RR simulation. Doing so could cause erroneous shortfall and work fetch. This means, however, that work buffering will not work as expected if you're using max concurrency.
2012-11-28 20:26:49 +00:00
// This file is part of BOINC.
// http://boinc.berkeley.edu
// Copyright (C) 2012 University of California
//
// BOINC is free software; you can redistribute it and/or modify it
// under the terms of the GNU Lesser General Public License
// as published by the Free Software Foundation,
// either version 3 of the License, or (at your option) any later version.
//
// BOINC is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
// See the GNU Lesser General Public License for more details.
//
// You should have received a copy of the GNU Lesser General Public License
// along with BOINC. If not, see <http://www.gnu.org/licenses/>.
#ifndef _APP_CONFIG_
#define _APP_CONFIG_
#include <vector>
#include "parse.h"
#include "client_types.h"
struct PROJECT;
struct RESULT;
struct APP_CONFIG {
char name[256];
int max_concurrent;
double gpu_gpu_usage;
double gpu_cpu_usage;
- scheduler: attempted performance enhancement. Old: each scheduler process holds a semaphore while scanning the shared-mem job array. On machines with many CPUs there seems to be contention for this semaphore, causing slow scheduler response and possibly connection failures. New: Don't hold the semaphore while scanning array. Instead, if find a job that passes quick_check(), acquire the semaphore and recheck that the job is present in array and passes quick_check(). - client: show messages if app_config.xml has unrecognized tags
2012-12-12 19:45:49 +00:00
int parse(XML_PARSER&, PROJECT*);
- client: add "client app configuration" feature; see http://boinc.berkeley.edu/trac/wiki/ClientAppConfig This lets users do the following: 1) limit the number of concurrent jobs of a given app (e.g. for WCG apps that are I/O-intensive) 2) Specify the CPU and GPU usage parameters of GPU versions of a given app. Implementation notes: - max app concurrency is enforced in 2 places: 1) when building the initial job run list 2) when enforcing the final job run list Both are needed to avoid possible starvation. - however, we don't enforce it during RR simulation. Doing so could cause erroneous shortfall and work fetch. This means, however, that work buffering will not work as expected if you're using max concurrency.
2012-11-28 20:26:49 +00:00
};
client: allow <app_version> elements in app_config.xml, allowing users to override the parameters of particular app versions
2013-09-06 22:41:43 +00:00
struct APP_VERSION_CONFIG {
char app_name[256];
char plan_class[256];
char cmdline[256];
double avg_ncpus;
double ngpus;
int parse(XML_PARSER&, PROJECT*);
};
- client: add "client app configuration" feature; see http://boinc.berkeley.edu/trac/wiki/ClientAppConfig This lets users do the following: 1) limit the number of concurrent jobs of a given app (e.g. for WCG apps that are I/O-intensive) 2) Specify the CPU and GPU usage parameters of GPU versions of a given app. Implementation notes: - max app concurrency is enforced in 2 places: 1) when building the initial job run list 2) when enforcing the final job run list Both are needed to avoid possible starvation. - however, we don't enforce it during RR simulation. Doing so could cause erroneous shortfall and work fetch. This means, however, that work buffering will not work as expected if you're using max concurrency.
2012-11-28 20:26:49 +00:00
struct APP_CONFIGS {
std::vector<APP_CONFIG> app_configs;
client: allow <app_version> elements in app_config.xml, allowing users to override the parameters of particular app versions
2013-09-06 22:41:43 +00:00
std::vector<APP_VERSION_CONFIG> app_version_configs;
- client: add "client app configuration" feature; see http://boinc.berkeley.edu/trac/wiki/ClientAppConfig This lets users do the following: 1) limit the number of concurrent jobs of a given app (e.g. for WCG apps that are I/O-intensive) 2) Specify the CPU and GPU usage parameters of GPU versions of a given app. Implementation notes: - max app concurrency is enforced in 2 places: 1) when building the initial job run list 2) when enforcing the final job run list Both are needed to avoid possible starvation. - however, we don't enforce it during RR simulation. Doing so could cause erroneous shortfall and work fetch. This means, however, that work buffering will not work as expected if you're using max concurrency.
2012-11-28 20:26:49 +00:00
- scheduler: attempted performance enhancement. Old: each scheduler process holds a semaphore while scanning the shared-mem job array. On machines with many CPUs there seems to be contention for this semaphore, causing slow scheduler response and possibly connection failures. New: Don't hold the semaphore while scanning array. Instead, if find a job that passes quick_check(), acquire the semaphore and recheck that the job is present in array and passes quick_check(). - client: show messages if app_config.xml has unrecognized tags
2012-12-12 19:45:49 +00:00
int parse(XML_PARSER&, PROJECT*);
int parse_file(FILE*, PROJECT*);
client: show app_config warnings only on startup and reread config
2013-05-19 17:02:00 +00:00
void config_app_versions(PROJECT*, bool show_warnings);
- client: add "client app configuration" feature; see http://boinc.berkeley.edu/trac/wiki/ClientAppConfig This lets users do the following: 1) limit the number of concurrent jobs of a given app (e.g. for WCG apps that are I/O-intensive) 2) Specify the CPU and GPU usage parameters of GPU versions of a given app. Implementation notes: - max app concurrency is enforced in 2 places: 1) when building the initial job run list 2) when enforcing the final job run list Both are needed to avoid possible starvation. - however, we don't enforce it during RR simulation. Doing so could cause erroneous shortfall and work fetch. This means, however, that work buffering will not work as expected if you're using max concurrency.
2012-11-28 20:26:49 +00:00
};
extern bool have_max_concurrent;
extern void max_concurrent_init();
extern void check_app_config();
#endif