|
|
|
Andreas Savva: 06/27/2007 10:56 AM EDT
|
| |
Comment: |
Verified in draft 10
|
| |
Action: |
Update
Closed set to 06/27/2007
Status changed from Fixed to Closed
|
|
|
Andreas Savva: 06/26/2007 6:08 AM EDT
|
| |
Comment: |
Incorporated new proposed text in draft 10
|
| |
Action: |
Update
Status changed from Resolved to Fixed
|
|
|
Andreas Savva: 06/20/2007 11:10 AM EDT
|
| |
Comment: |
Proposed text seems good.
|
| |
Action: |
Update
Status changed from Pending to Resolved
|
|
|
Andreas Savva: 06/13/2007 11:05 AM EDT
|
| |
Comment: |
Suggested replacement text for the
* IndividualCPUTime
If this element is used with an upper bound, then this value acts as a ceiling on the number of CPU seconds that a job will consume on an individual
resource. If the job exceeds this value, the consuming system MAY terminate the job.
If this element is used with a lower bound, then this value acts as a floor on the number of CPU seconds that a job is guaranteed to consume on an
individual resource. The consuming system SHOULD NOT terminate the job before the lower bound is reached.
There is an expectation that the required CPU seconds will be consumed within a reasonably contiguous time period.
This element should be considered in conjunction with applicable scheduling attributes, which may defined in other specifications.
* With analogous text for TotalCPUTime
|
| |
Action: |
Update
|
|
|
Donal Fellows: 06/11/2007 11:14 AM EDT
|
| |
Comment: |
These elements describe resource requirements. Resource requirements may be implemented with limits, but implementors are not constrained to do so (e.
g. when using a virtualization environment, other choices may be possible). By contrast, a CPU time limit (as described in the POSIX extension) means
exactly that, and that includes all the implied stuff about getting a catchable SIGXCPU signal when the limit is exceeded.
When someone specificies a resource requirement, they give the range of values which are acceptable to them; with CPU times, they'll typically give a
non-zero lower bound and might or might not give an upper bound (a job pricing model would be needed to persuade people to give a non-infinite upper
bound, of course, but that's the meaning.) It is up to the batch engine (as modified by any policies) to decide how much CPU time to allocate to a job
; as long as it is in the range given by the user, it is acceptable. If an implementation decides to implement resource management through setting CPU
time limits, it might decide to set the limit lower than the POSIX limit level requested; in that case it probably shouldn't set the limit to higher
than the amount allocated. I hope this is clear.
I've no idea how to implement a TotalCPUTime resource. :-)
|
| |
Action: |
Update
|
|
|
Andreas Savva: 05/07/2007 11:47 AM EDT
|
| |
Comment: |
No consensus on text. Discuss again with Donal and Chris.
|
| |
Action: |
Update
Assigned To changed from Chris Smith to Donal Fellows
Status changed from Fixed to Pending
|
|
|
Andreas Savva: 03/07/2007 4:48 AM EST
|
| |
Comment: |
I've added the supplied text in draft 2 with some minor editorial changes.
|
| |
Action: |
Update
Status changed from Resolved to Fixed
|
|
|
Chris Smith: 01/25/2007 8:20 PM EST
|
| |
Comment: |
Here is my suggestion for additional text on...
IndividualCPUTime:
If this element is used with an upper bound, then this value acts as an upper limit on the number of CPU seconds that a job will consume on an
individual resource. If the job exceeds this limit, the consuming system is free to terminate the job.
If this element is used with a lower bound, indicating a lower limit on the number of CPU seconds that the job will consume on the resource, then the
evaluation of this element needs to be done in conjunction with another JSDL element or non-JSDL extension element that causes evaluation of this
limit within a finite time period, or else the lower limit requirement becomes trivially true, as any resource has a theoretical infinite number of
CPU seconds available.
For example, a lower limit on CPU seconds could be evaluated within a given period of time if the jsdl-posix:WallClockLimit is provided, where the
time period is the job's wall clock starting time plus the duration given by jsdl-posix:WallClockLimit.
TotalCPUTime:
If this element is used with an upper bound, then this value acts as an upper limit on the number of CPU seconds that a job will consume on all
allocated resources. If the job exceeds this limit, the consuming system is free to terminate the job.
If this element is used with a lower bound, indicating a lower limit on the number of CPU seconds that the job will consume on the resource, then the
evaluation of this element needs to be done in conjunction with another JSDL element or non-JSDL extension element that causes evaluation of this
limit within a finite time period, or else the lower limit requirement becomes trivially true, as any resource has a theoretical infinite number of
CPU seconds available.
For example, a lower limit on CPU seconds could be evaluated within a given period of time if the jsdl-posix:WallClockLimit is provided, where the
time period is the job's wall clock starting time plus the duration given by jsdl-posix:WallClockLimit.
|
| |
Action: |
Update
|
|
|
Andreas Savva: 01/17/2007 9:42 AM EST
|
| |
Comment: |
Add clarification that there is a period applied so that the lower limit makes sense. The definition of this period is not part of 1.0 or 1.1 (
scheduling).
upper bound is ok without any period.
|
| |
Action: |
Update
Assigned To set to Chris Smith
Status changed from Open to Resolved
|
|
|
|
