[Swift-user] Specifying coastersPerNode on sites that place jobs by CPU

Michael Wilde 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 
> them).

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