[Swift-devel] Re: replication vs site score

[Ioan Raicu]

There are use cases where static resource allocation are better than 
dynamic ones. Again, we come back to the BG/P system. There is a policy 
that only allows you to submit X number of jobs to Cobalt, and X is < 10 
jobs. Now, if you want to allocate resources dynamically, in smaller 
chunks, you are limited to only a few jobs. Static provisioning all of a 
sudden seems attractive.

Another thing that you have to remember, that for some systems, like the 
BG/P, getting 2 allocations of 64 nodes each, is not the same as getting 
1 allocation of 128 nodes. The 1 single allocation of 128 nodes has 
networking configured in such a way to allow node-to-node communication 
efficiently. The 2 separate allocations, could be allocated in 
completely opposite ends of the system, and hence having poor networking 
properties to do node-to-node communication, between the separate 
allocations (if its even possible, I am not sure, the networks might be 
completely separate). This might not be important for vanilla Swift, but 
some of the MTDM work (previously known as collective I/O) relies on 
good network connectivity between any node in the allocation to pass 
data around and avoiding GPFS.

Ioan

Mihael Hategan wrote:
> On Thu, 2009-04-09 at 11:51 -0500, Ian Foster wrote:
>   
>> I didn't appreciate that about Coaster. It should (IMHO) support
>> static allocation, as a special case. People will clearly want that.
>>     
>
> Yes. People clearly make irrational choices.
>
>   
>>
>> On Apr 9, 2009, at 11:49 AM, Ioan Raicu wrote:
>>
>>     
>>> Right, Falkon supports both static and dynamic allocation of
>>> resources. I believe coaster only supports dynamic allocation of
>>> resources. We have lots of information under static allocation, that
>>> could help scheduling, but under dynamic allocation, there is a
>>> mixture of known information (the already allocated resources) and
>>> the unknown (the jobs in the wait queue). In a sense, a smarter
>>> scheduler could make use of at least known information, although
>>> this information might frequently change, and the scheduler would
>>> have to adapt frequently.
>>>
>>> Ioan
>>>
>>> Ben Clifford wrote: 
>>>       
>>>> On Thu, 9 Apr 2009, Ian Foster wrote:
>>>>
>>>>   
>>>>         
>>>>> I wanted to point out that when we use Falkon/coasters, we have full control
>>>>> over scheduling, so in that case we could in principle pre-compute schedules.
>>>>>     
>>>>>           
>>>> Coasters as they are now are still allocated on an opportunistic basis, so 
>>>> once we have a coaster stuff could be scheduled to it, but when coaster 
>>>> workers actually exist is as unknown as when jobs will run in the 
>>>> non-coaster case, I think.
>>>>
>>>> Where Falkon has been used for pre-allocated resources on machines, with 
>>>> no dynamic allocation/unallocation, though, the available resources 
>>>> probably are known well enough for this.
>>>>
>>>>   
>>>>         
>>>>> However, in practice we still don't tend to have enough information about
>>>>> execution times for this to be that useful. At least that's my belief.
>>>>>     
>>>>>           
>>>> yes.
>>>>
>>>>   
>>>>         
>>> -- 
>>> ===================================================
>>> Ioan Raicu, Ph.D.
>>> ===================================================
>>> Distributed Systems Laboratory
>>> Computer Science Department
>>> University of Chicago
>>> 1100 E. 58th Street, Ryerson Hall
>>> Chicago, IL 60637
>>> ===================================================
>>> Email: iraicu at cs.uchicago.edu
>>> Web:   http://www.cs.uchicago.edu/~iraicu
>>> http://dev.globus.org/wiki/Incubator/Falkon
>>> http://dsl-wiki.cs.uchicago.edu/index.php/Main_Page
>>> ===================================================
>>> ===================================================
>>> _______________________________________________
>>> Swift-devel mailing list
>>> Swift-devel at ci.uchicago.edu
>>> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
>>>       
>> _______________________________________________
>> Swift-devel mailing list
>> Swift-devel at ci.uchicago.edu
>> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
>>     
>
>
>   

-- 
===================================================
Ioan Raicu, Ph.D.
===================================================
Distributed Systems Laboratory
Computer Science Department
University of Chicago
1100 E. 58th Street, Ryerson Hall
Chicago, IL 60637
===================================================
Email: iraicu at cs.uchicago.edu
Web:   http://www.cs.uchicago.edu/~iraicu
http://dev.globus.org/wiki/Incubator/Falkon
http://dsl-wiki.cs.uchicago.edu/index.php/Main_Page
===================================================
===================================================

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