From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] python-smartpm: Add an attempt install mode
Date: Wed, 11 Sep 2013 15:29:55 +0100 [thread overview]
Message-ID: <9578359.7iYYtX4lxh@helios> (raw)
In-Reply-To: <52307475.9090901@windriver.com>
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
prev parent reply other threads:[~2013-09-11 14:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-11 1:59 [PATCH] python-smartpm: Add an attempt install mode Mark Hatle
2013-09-11 2:04 ` Mark Hatle
2013-09-11 10:04 ` Paul Eggleton
2013-09-11 13:47 ` Mark Hatle
2013-09-11 14:29 ` Paul Eggleton [this message]
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=9578359.7iYYtX4lxh@helios \
--to=paul.eggleton@linux.intel.com \
--cc=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox