[Swift-devel] Falkon and Coaster support for MPI

Ben Clifford benc at hawaga.org.uk
Mon Jun 30 03:54:52 CDT 2008


On Mon, 30 Jun 2008, Ian Foster wrote:

> 1) It must be straightforward to submit MPI programs from Swift, via the GRAM
> provider--the only issue is passing the appropriate parameters to the GRAM

[...]

> 2) The challenge is doing this in conjunction with multi-level scheduling (aka
> Falkon/Coaster/Glideins), which we may require for reasons of feasibility (on

[...]

> 3) So my view is that we want to set up Swift to support both modes (1) and
> (2).

yes.

> 
> 4) Ioan points out that a fully general multi-level scheduling solution with
> support for multi-CPU jobs may introduce the need for a smarter scheduler than
> our current FIFO approach. E.g., if we have 256 nodes and a queue with jobs of
> size {32,256,32,32,32,32,32,32,32,32}, a FIFO strategy would run them in that
> order, and waste much CPU time. On the other hand, a simple "first-fit"
> strategy might starve large jobs.
> 
> I think we should be nervous about getting into the business of implementing
> scheduler functionality like this.

yes. certainly the coaster code should not at the moment be getting into 
doing 'fancy' stuff.

> I'd like to advocate that in the short term, we try to make this problem go
> away by requiring that if an application includes MPI tasks, they all be of
> the same size.

right. I pretty much agree with that constraint, or something fairly 
similar, eg by saying that we will only do first-come-first-serve queueing 
that probably ties uniform job size strongly to worker efficiency.

> 5) The question has been raised of how to implement (2). One proposal is 
> to adapt coaster to support MPI jobs. I'm a bit concerned that this 
> could be expensive: we already have Falkon running well on BG/P, and 
> given our other commitments to support NSF user communities, putting 
> scarce resources into replicating that work may not be optimal.

This is not the thread to debate falkon vs coaster. The development model 
for that has been extensively debated in the past.

-- 



More information about the Swift-devel mailing list