I like the proposal, makes sense to me. Best regards, Peter. Am 01.06.11 23:16, schrieb Mariusz Mamoński:
Hi, a new spreadsheet tab wich tries to summarize how different resource limits are handled in GE/LSF/Torque:
and the proposition of restructuring the section 5.6.25 ( text in brackets [] == my comment):
5.6.26 resourceLimits [not hardResourceLimits]
This attribute specifies the limits on resource utilization of the job(s) on the execution host(s). The valid dictionary keys and their value semantics are defined in Section 4.3.
The CORE_FILE_SIZE, DATA_SEG_SIZE, FILE_SIZE, OPEN_FILES, STACK_SIZE, VIRTUAL_MEMORY limits SHOULD be implemented as the soft resource limits. An implementation MAY map them to an setrlimit call in the operating system. [I think the actual usecase for those resources is to increase the system default limit rather than actually limit the application]
The WALLCLOCK_TIME and CPU_TIME should be implemented as hard resource limits, i.e. exceeding the resource limit SHOULD eventually lead to termination of a job either by the DRM system or the application itself. The DRM system MAY frist notify the application upon reaching the limit (e.g. by sending a signal that can be handled) before trying to ultimately terminate it (e.g. by sending SIGKILL signal).
All the resource limits SHOULD be enforced on per process [not job] basics.
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg