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

[Michael Wilde]

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.