daniel.templeton at oracle.com
Mon Nov 8 09:05:25 CST 2010
The slotsCount attribute would be challenging for something like OGE,
where the number of slots available on a machine is taken from the sum
of the slots in all the enabled queue instances on that machine modulo
the active resource quota sets modulo any host-level slots settings
modulo the queue subordination rules. It's also not very meaningful,
because many of those things can and do change dynamically.
On 11/ 8/10 07:01 AM, Mariusz Mamoński wrote:
> Hi all,
> If we are talking about the monitoring session... what do you think
> about the idea of:
> 1. creating a new data struct MachineInfo with all the predefined
> machine attributes (e.g.: threadsPerCore) + "readonly attribute
> Dictionary drmsSpecific;" (an extension point) and providing one
> method: "MachineInfo getMachineInfo(in string machineName) for
> accessing all of them
> 2. adding a new attribute "slotsCount", which denotes the maximum
> number of single-process jobs that can run on given machine
> concurrently (use case: system administrator may either choose
> configuration where one process runs per physical core or hardware
> thread or choose choose any number that is totally independent from
> hardware configuration)
> 2010/11/8 Daniel Gruber<daniel.x.gruber at oracle.com>:
>> Ok. For simplicity we take 1 as default value with the
>> drawback that we loose information if the SMT value
>> is available (and correct) or not.
>> On 11/08/10 15:14, Peter Tröger wrote:
>>> I can agree to the new "threadsPerCore" attribute, but would prefer to have "1" as default value. From our understanding of a core, each one can always execute at least one thread. It would also allow to compute an estimation of the number of parallel threads, without looking on the specific numbers.
>>> Am 08.11.2010 um 10:55 schrieb Daniel Gruber:
>>>> in the MonitorinSession we have on machine level machineSockets and coresPerSocket.
>>>> To be consequent we should also add threadsPerCore. At least OGE/SGE does
>>>> support this. I added it into our spreadsheet.
>>>> If this is not supported by a DRM/OS it could return 0 as value for unknown.
>>>> 0 for coresPerSocket and machineSockets is not allowed since we should
>>>> define coresPerSocket*machineSockets=="processors" in case a DRM or OS
>>>> does not support this kind of architectural information. I suggest to leave
>>>> it open for the DRMAA implementation if it maps the "processors" information
>>>> to coresPerSocket or machineSockets in case of missing architectural
>>>> If there is no objection I'll take this as accepted.
>>>> drmaa-wg mailing list
>>>> drmaa-wg at ogf.org
>> drmaa-wg mailing list
>> drmaa-wg at ogf.org
More information about the drmaa-wg