Post by Mariusz MamoÅskiCan 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.
Post by Mariusz MamoÅskiWe 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
- 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
Post by Mariusz MamoÅskiCheers,
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
Post by Mariusz MamoÅskiHi all,
If we are talking about the monitoring session... what do you think
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,
Post by Daniel GruberOk. 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
Post by Peter TrögerHi,
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.
Post by Daniel GruberHi,
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