On Wednesday 11 September 2013 08:47:33 Mark Hatle wrote: > On 9/11/13 5:04 AM, Paul Eggleton wrote: > > On Tuesday 10 September 2013 21:04:29 Mark Hatle wrote: > >> Time measurements with: > >> > >> MACHINE = "qemux86" > >> PACKAGE_CLASSES = "package_rpm" > >> EXTRA_IMAGE_FEATURES = "dev-pkgs staticdev-pkgs doc-pkgs dbg-pkgs > >> ptest-pkgs" BB_NUMBER_THREADS ?= "8" > >> PARALLEL_MAKE ?= "-j 8" > >> > >> image: core-image-sato > >> > >> Quad Core i7 workstation... > >> > >> With all of the recipes built, and just executing the do_rootfs: > >> > >> Before this change: > >> real 26m2.541s > >> user 21m8.458s > >> sys 7m9.683s > >> > >> After this change: > >> real 14m43.436s > >> user 15m57.525s > >> sys 5m16.412s > >> > >> This is a significant performance boost when using the 'complementary' > >> installs and attemptonly installs. The performance is by doing the > >> complementary installs as a batch instead of one at a time, ignoring > >> failures. > > > > This is a significant improvement, well done! My concern about not > > catching > > failures stands though, which is why I hadn't implemented this yet. How do > > we ensure that genuine failures are caught with this mode? > > The code only ignores failures in the resolution of the dependencies. As > far as I'm aware, this is the correct behavior in the attempt only mode(s). > If the dependencies can't be resolved for some reason, we simply throw > away that item and move on. > > Any errors that occur during package installation -will- now cause a failure > to exist, and they will be logged to the attemptonly log-file. > > In the previous implementation, any error when installing an attemptonly > package would be ignored, even if it turned out to be an installation > problem and not a dependency issue. So I think this is an improvement as > well. > > (For some of my testing I intentionally created dependency errors by adding > things to the PACKAGE_EXCLUDE, and the system did what it was supposed to. > Ignored the items that couldn't be installed.)
Sounds like a great improvement. Thanks! Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
