[Swift-user] Specifying coastersPerNode on sites that place jobs by CPU
wilde at mcs.anl.gov
Fri Apr 3 07:55:16 CDT 2009
On 4/3/09 2:41 AM, Ben Clifford wrote:
> On Fri, 3 Apr 2009, Ben Clifford wrote:
>>> Some sites, like TeraPort, (I think) place independent jobs on all CPUS.
>>> When using coasters, is it true that the user should not specify
>>> coastersPerNode? Or at least not set it to > 1?
>> Pretty much, yes.
> * Although it provides way to get node overcomitting, which I think in
> some applications is good (i.e. we have two cores, try to run 4 jobs on
Sounds reasonable; would be good to try for IO-bound jobs.
> * If you're running on a node that allocates jobs per CPU by default, its
> probably going to present less load to the worker submission system (eg
> GRAM2 or PBS) if you can make it submit one per physical machine and have
> coastersPerNode allocate the CPUs instead of PBS. This is what you'd do in
> qsub with the ppn option. Off the top of my head, I don't know how (or if
> its possible at all) with coasters+gram2+pbs.
I see the possibility (this could make the "allocate all the cores I
want in one job" feature work for us today with no code change).
But I dont understand the mechanism, even w/o GRAM. Youre implying this
would work with coasters today, in provider=local:pbs mode, right?
But how would you specify it? Lets say you want 32 cores, on teraport.
if you say coastersPerNode=32, you would get 32 coasters per core
(overcommiting, as before).
Did you mean "If you're running on a node that allocates jobs per HOST
by default"? Eg, systems like Abe and Ranger, the systems with
substantial cores per host (8,16)? So say we run on Abe, which I think
has PBS, and say coastersPerNode=32, you think we would get 4 hosts
running 32 coasters, 8 per host, 1 per core? That would be cool to try,
and then to try over GRAM. But this direction depends somewhat on how
Mihael will specify and design the coaster provisioning feature.
More information about the Swift-user