[DRMAA-WG] MonitoringSession

[Daniel Gruber]

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. 

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
>>
> 
> 
>