Re: Can anything be done about do_rootfs speed?

[Gary Thomas <gary@mlbassoc.com>]

On 2013-08-27 16:27, Paul D. DeRocco wrote:
> I got really tired of waiting for builds on my lowly dual-core Atom
> machine, so I went out and bought a nice fast machine with an i7-4770K and
> a Samsung SSD. Full builds are now screechingly fast, over 10x compared to
> the Atom.
>
> But when making a tiny change, I still have to wait for do_rootfs. Since
> this is a single task, it runs on a single core, so it only runs maybe
> three times as fast. For my Gumstix stuff, it takes five minutes instead
> of something like 15. That's a meaningful improvement, but it still seems
> long when the task implementing the minor change took, oh, five seconds.
> Since it's the one task that _always_ gets executed, it seems like a
> bottleneck that should be addressed.
>
> Is there any way, in the future, of breaking do_rootfs into multiple
> threads, so they can take advantage of multiple cores? Or has something
> like this been tried already, and found not to produce much of a speedup?
> Or is the process intriniscally sequential?
>

As far as I understand, the 'do_rootfs' step in building an image is basically
equivalent to running "${PKG_MGR} install <all_required_packages>", where PKG_MGR
is your package management method of choice - ipk or rpm.  This seems to me to
be a very single-threaded process.

Perhaps you should think more about how you are using this.  If you don't need
to rebuild the whole image every time, maybe you can use the package management
tools instead?  For example, I routinely build images as well but I also try to
use 'opkg' as much as possible to manage package updates, etc.   This is a huge
time saver, especially when making small or incremental changes.  I only rely
on the full image builds when I want to "checkpoint" the state of the system.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------