[DRMAA-WG] MonitoringSession

[Daniel Gruber]

On 11/08/10 16:58, Mariusz Mamoński wrote:
> Can we split the discussion into two paths? ;-)
> 
> Does anyone vote against 1. point (MachineInfo)?
> 

When there is a method "getMachineInfo(in string machineName)"
we would also require "getQueueInfo(in stirng queueName)" for 
consistency. Then in total we would have "getQueueNames", 
"getMachineNames", "getMachineInfo", "getQueueInfo", 
and "getAllJobs". Which would result in a pretty clear 
interface. But the current approach has its strengths in 
simplicity when accessing the values. I would keep the interface 
simple and portable in case of monitoring since this is IMHO 
not our core competence. Hence I would keep the current 
approach and vote against it.

> Regarding 2. point:
> 
>  We could make maxSlotsCount optional (like the threadsPerCore) and
> define it only as the upper bound (and only for the purpose of
> computing host/cluster "capacity"). Alternatively: what do you think
> about the idea of:
>   - changing threadsPerCore -> maxThreads
>   - relaxing meaning of the threadsPerCore/maxThreads: as "maximal
> number of threads that can run *simultaneously* on given machine"
> without saying if this is imposed by hardware configuration or system
> policy.

The other machine values (load, sockets, cores, threads, physical mem,
virtual mem, machine os, OS version, machine arch) are not user dependent
hence it would break consistency. Queue values should be user dependent. 

Daniel

> 
> Cheers,
> 
> 
> 2010/11/8 Daniel Gruber <daniel.x.gruber at oracle.com>:
>> Adding slotsCount to machineInfo would destroy the separation between queue
>> level and host level information. Different users could have different
>> slotCount on the same machine. The information must be retrieved on queue
>> level (we have the queueMaxSlotsAllowed()) method for that.
> but in this case the slots can spawn multiple hosts
>> Cheers
>>
>> Daniel
>>
>>
>> On 11/08/10 16:01, 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)
>>>
>>> Cheers,
>>>
>>>
>>> 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.
>>>>
>>>> Regards,
>>>>
>>>> Daniel
>>>>
>>>> On 11/08/10 15:14, Peter Tröger wrote:
>>>>> Hi,
>>>>>
>>>>> 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.
>>>>>
>>>>> Best,
>>>>> Peter.
>>>>>
>>>>>
>>>>> Am 08.11.2010 um 10:55 schrieb Daniel Gruber:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> 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
>>>>>> details.
>>>>>>
>>>>>> If there is no objection I'll take this as accepted.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Daniel
>>>>>> --
>>>>>>  drmaa-wg mailing list
>>>>>>  drmaa-wg at ogf.org
>>>>>>  http://www.ogf.org/mailman/listinfo/drmaa-wg
>>>> --
>>>>  drmaa-wg mailing list
>>>>  drmaa-wg at ogf.org
>>>>  http://www.ogf.org/mailman/listinfo/drmaa-wg
>>>>
>>>
>>>
>>
> 
> 
>