From: Mark Hatle <mark.hatle@windriver.com>
To: <yocto@yoctoproject.org>
Subject: Re: Bitbake and task offloading onto multiple cloud-based servers
Date: Fri, 4 Jan 2013 16:43:12 -0600 [thread overview]
Message-ID: <50E75B00.1000307@windriver.com> (raw)
In-Reply-To: <50E741F0.50303@dynamicdevices.co.uk>
On 1/4/13 2:56 PM, Alex J Lennon wrote:
>
> Can anybody advise on whether bitbake currently supports offloading of
> build tasks onto multiple systems? Perhaps cloud based?
I see Chris Larson has already answer the main question here.. but I've got some
additional insight I can add.
> I'm thinking that it would be more efficient for me if I could bring up
> a number of Amazon EC2 servers (or similar) then have bitbake
> parallelise the build onto those servers to significantly reduce my
> build times?
In the past I've had people ask me questions about remote builds, parallel
building packages, etc. In the past when I've attempted to figure out if it
would be useful, the cost of the data transfer time always comes into play. How
long does it take to simply perform the task locally vs go to the remote
machine, perform the task, and get the data back. For a lot of the tasks that
OE does, the remote tasks will end up being slower on a reasonably modern i7 (or
similar Xeon) machine. I'm not sure using something like a cloud server would
end up helping due to this.
From experience I'd say that if anything you'd likely want to modify the
bitbake scheduler with some type of locality information. I.e. if you extract
the sources on a node, you most likely want to patch, configure, compile,
install, QA and package on that node as well.... but that also means a way to
establish node specific tmp/work space is needed for performance as well.
> I see bitbake supports a level of task parallelisation on a single box.
>
> Can parallelisation of build onto multiple systems be achieved?
All of the above are possible, but I suspect there is a lot of design and
refactoring required to come up with a system that is both efficient and fast.
> Is it something that should even be a goal?
It's not currently a goal. But it does get asked about every now and then. It
would be nice to have something more then anecdotal information about if it
would be a good idea or not. This is the type of thing that I think would make
an excellent research project. (Hey and if it makes things able to be built for
more people, faster, and cheaper great! If not, we'd have a more informed
response to questions like this.)
--Mark
> Cheers,
>
> Alex
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
next prev parent reply other threads:[~2013-01-04 22:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-24 7:37 Fails to launch the hob Biao
2012-12-24 12:23 ` Mihai Lindner
2012-12-24 12:37 ` Mihai Lindner
2012-12-25 6:16 ` Biao
2013-01-03 16:47 ` Barros Pena, Belen
2013-01-03 23:11 ` Zhang, Jessica
2013-01-04 10:10 ` Barros Pena, Belen
2013-01-04 16:57 ` Barros Pena, Belen
2013-01-04 20:56 ` Bitbake and task offloading onto multiple cloud-based servers Alex J Lennon
2013-01-04 21:08 ` Chris Larson
2013-01-04 21:17 ` Alex J Lennon
2013-01-04 21:27 ` Chris Larson
2013-01-08 23:12 ` Tom Zanussi
2013-01-09 11:58 ` Alex J Lennon
2013-01-09 15:43 ` Tom Zanussi
2013-01-04 22:43 ` Mark Hatle [this message]
2013-01-04 22:47 ` Alex J Lennon
2013-01-04 23:14 ` Flanagan, Elizabeth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50E75B00.1000307@windriver.com \
--to=mark.hatle@windriver.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.