Karl Czajkowski wrote:
On Apr 20, Andreas Savva loaded a tape reading:
I meant that if a resource description is given as <Resource> <CPUCount> <Exact> 2.0 </Exact> </CPUCount> </Resource>
it means a 2-cpu host. Not 2 CPUs from a possibly larger N CPU machine.
Yes, this is indeed the "latter" case from Chris. I had hoped we didn't care about the aspects of a resource _not_ allocated to us.
Why do you actually care whether your 2 CPUs are a whole host or not? Is this actually some sort of selection preference sneaking in, like do not give me the more rare nodes? Or is it a QoS issue like "exclusivity" of the resource? I think it is important that we understand why you want to express this, now that it is clear what you are expressing.
Do you expect to express similar physical constraints on other resources not necessarily allocated to you, e.g. amount of RAM or virtual memory space not necessarily allocated to you? I'm not trying to be snarky but this avenue does confuse me lots!
My requirement is very simple. If I ask for a 2-way SMP machine I want a 2-way SMP machine and nothing else. It is not a preference. Consider that I may want to run software specifically tuned to some configuration (cpu, ram, and so on) and I don't want the system to be 'helpful' and give me something that it thinks is better for me. Unless I tell it so by using a range expression. Obviously this has nothing (or doesn't necessarily) have to do with 'process topology.'
If on the other hand I said <Resource> <CPUCount> <LowerBoundedRange> 2.0 </LowerBoundedRange> </CPUCount> </Resource>
I would accept any machine with at least 2 CPUs.
I find this ambiguous again... you need to distinguish again acceptance of an allocation from acceptance of characteristics of a resource that have not been allocated to you!
Not sure what was ambiguous; maybe the "I would accept.." part? Perhaps I should say instead that the above fragment to me means "I want a host with at least 2 cpus."
So the (my?) definition would be closer to Chris' second definition.
Maybe we should leave the rest until we can clarify what is the correct definition of resource multiplicity (and what other people think the correct meaning of the above fragments are....)
Andreas
It seems to me the issue of resource element mulitplicity is orthogonal... it is whether we support heterogeneous resource requirements or not, e.g. some number of resources that look like THIS and some other number of resources that look like THAT.
I agree that we are mixing in too many concepts. For 'process topology' let's just focus on a single resource element.
As for you parenthetic comment, I think it is useless to investigate "what people think the correct meaning of [...] fragments are" but rather we should focus on what meanings do we want to convey in JSDL and then fix the syntax to do so unambiguously.
True. But I assume (hope rather) there is already some consensus on what those fragments mean and would hate to try to start from scratch.
It sounds to me like you are advocating the full set of concepts I suggested in my earlier message:
I think we are not that far apart. Just to map these to what I've been using:
allocated CPUs per resource
I guess 'similar' to TileSize at the moment.
total allocated CPUs
'ProcessCount' I guess.
installed CPUs per resource (your 2-cpu machine)
CPUCount
As Chris said, using range value expressions on "allocated CPUs per resource" will give us tile size, e.g. I want 2,4,8,16 CPUs per resource (but not 7 etc.) and I want between 32 and 128 CPUs total.
One thing that confuses me is whether there needs to be a way to express symmetry or "strict homegeneity" e.g.
4 nodes, each with 4 cpus OR 4 nodes, each with 8 cpus
versus
4 nodes, each with 4 or 8 cpus
I think the latter is what we know how to express right now using exact resource counts, by considering them equivalent to unrolling into a fixed number of resource elements. I do not know if others intended this or the stricter symmetric interpretation.
karl
Yes. What we have in the spec right now can express the latter version but not the former. We don't have an 'OR' operator. I think the former is where we should start to be thinking of combining JSDL with other specs like WS-Agreement. -- Andreas Savva Fujitsu Laboratories Ltd