[Swift-devel] Re: replication vs site score

Ian Foster foster at anl.gov
Mon Apr 6 09:46:29 CDT 2009


Ben:

You may recall the work that was done by Greg Maleciwz (sp?) on  
prioritizing jobs that enable new jobs to run. Those ideas seem  
relevant here.

I met last week with a smart fellow in Singapore, Qin Zheng (CCed  
here), who has been working on the scheduling of replicant jobs. His  
interest is in doing this for jobs that have failed, while I think  
your interest is in scheduling for jobs that may have failed--a  
somewhat different thing. But there may be a connection.

Ian.


On Apr 6, 2009, at 9:39 AM, Ben Clifford wrote:

> even more rambling... in the context of a scheduler that is doing  
> things
> like prioritising jobs based on more than the order that Swift  
> happened to
> submit them (hopefully I will have a student for this in the  
> summer), I
> think a replicant job should be pushed toward later execution rather  
> than
> earlier execution to reduce the number of replicant jobs in the  
> system at
> any one time.
>
> This is because I suspect (though I have gathered no numerical  
> evidence)
> that given the choice between submitting a fresh job and a replicant  
> job
> (making up terminology here too... mmm), it is almost always better to
> submit the fresh job. Either we end up submitting the replicant job
> eventually (in which case we are no worse off than if we submitted the
> replicant first and then a fresh job); or by delaying the replicant  
> job we
> give that replicant's original a chance to start running and thus do  
> not
> discard our precious time-and-load-dollars that we have already  
> spent on
> queueing that replicant's original.
>
> --
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20090406/14a956fb/attachment.html>


More information about the Swift-devel mailing list