[Swift-devel] Re: GRAM and Swift discussion this week?
Mihael Hategan
hategan at mcs.anl.gov
Wed May 23 04:10:42 CDT 2007
On 05/23/2007 06:10:59 AM, Tim Freeman wrote:
> On Tue, 22 May 2007 14:34:07 -0500
> Ioan Raicu <iraicu at cs.uchicago.edu> wrote:
>
> > the many logs that we generate are quite hard for people to
> > follow, and keep track of what each one contains; we fixed
> this by
> > developing a GUI that can connect to the GT4 container
> remotely
> > and display relevant information!
>
> Is that something that could be used for other GT services?
>
>
> > * the provisioner currently creates a new thread for every
> job
> > (resource allocation) it sends to GRAM4
> > o depending on which allocation strategy is used,
> this
> > might/might not be a problem on TG nodes
> > o in theory, we don't want more than 100 or so GRAM4
> > jobs in parallel running, but if we choose the
> policy
> > in which each job allocates a single machine, then
> we
> > can easily surpass 100 jobs in parallel... all the
> > other policies, would be able to allocate 1K+,
> even
> > 10K+ machines with less than 100 jobs in parallel,
> so
> > it could work perfectly fine even with the current
> > implementation; in the long run, this might be
> able to
> > be changed to a pool of threads in the
> provisioner!
>
> Are these threads just waiting on notifications?
>
> If so: you should be able to reduce this to one thread by subscribing
> with the
> same notification consumer EPR for each GRAM job and demuxing the
> result (demux
> based on the producer EPR that is passed to the class implementing
> NotifyCallback). That way the thread that creates the GRAM job can
> disappear
> once it is done with the create call.
I'd recommend the CoG abstractions. They do exactly that, but hide all
the details.
Mihael
>
> Tim
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
>
>
More information about the Swift-devel
mailing list