[DRMAA-WG] Conference call - June 1th - 19:00 UTC

[Peter Tröger]

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:
>
> https://spreadsheets.google.com/spreadsheet/ccc?key=0AqyvnBscJNqxcnJBSUs5dXRrU29EUVhGOGthc1lDTFE&hl=en_US#gid=13
>
> 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 at ogf.org
>>   http://www.ogf.org/mailman/listinfo/drmaa-wg
>>
>
>
>