From: Patrick Ohly <patrick.ohly@intel.com>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 3/3] rm_work.bbclass: clean up sooner
Date: Thu, 16 Feb 2017 11:26:54 +0100 [thread overview]
Message-ID: <1487240814.13854.449.camel@intel.com> (raw)
In-Reply-To: <CA+chaQebkND=ipbVvDGAJo=o79SsucECyyNgaaMRYyiOuVqZ2g@mail.gmail.com>
On Wed, 2017-02-15 at 19:32 +0100, Martin Jansa wrote:
> Are all changes necessary for this to work already in master?
Yes.
> Yesterday I've noticed that rm_work for some components which are
> early in the dependency (like qtbase) are executed relatively late
> (together with do_package_qa).
Could do_rm_work run before do_package_qa? rm_work.bbclass doesn't know
that, and therefore schedules do_rm_work after do_package_qa.
If yes, then adding a list of tasks that can be ignored would be
trivial. This can be a variable, so a recipe can even add their own
ones, if necessary.
> So I've tried very naive way to find out if the rm_work tasks are
> executed sooner or not just by comparing Task IDs in build of the same
> image built from scratch (without sstate) with Dizzy, Morty and
> current master.
Interesting, I hadn't thought of testing it like that.
> If we dismiss the strange case in rm_work.tasks.master.qemux86 then it
> seems to perform at least as good as old completion BB_SCHEDULER.
>
>
> But I wanted to ask if there is something else we can do or you were
> planing to do, because IIRC you shared some longer analysis of what
> could be improved here and I'm not sure if you managed to implement it
> all.
The other ideas that I mentioned at some point didn't pan out as
intended. In particular allowing do_rm_work tasks to run when the normal
task limit was reached didn't have a big effect and the implementation
was a hack, so I dropped that.
> It feels to me that rm_work has high priority, but still it's
> "blocked" by e.g. do_package_qa which gets executed late and then
> immediately followed by rm_work.
That should be easy to change, perhaps like this (untested):
RM_WORK_TASKS_WHITELIST = "do_build do_package_qa"
deps = set(bb.build.preceedtask('do_build', True, d))
whitelist = d.getVar('RM_WORK_TASKS_WHITELIST').split()
deps.difference_update(whitelist)
# In practice, addtask() here merely updates the dependencies.
bb.build.addtask('do_rm_work', 'do_build', ' '.join(deps), d)
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
next prev parent reply other threads:[~2017-02-16 10:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-06 9:55 [PATCH 0/3] rm_work enhancements Patrick Ohly
2017-01-06 9:55 ` [PATCH 1/3] gcc-source.inc: cleanly disable do_rm_work Patrick Ohly
2017-01-09 18:47 ` Khem Raj
2017-01-06 9:55 ` [PATCH 2/3] rm_work_and_downloads.bbclass: more aggressively minimize disk usage Patrick Ohly
2017-01-06 18:31 ` Randy Witt
2017-01-06 19:22 ` Patrick Ohly
2017-01-06 21:29 ` Randy Witt
2017-01-07 8:09 ` Patrick Ohly
2017-01-09 10:25 ` Patrick Ohly
2017-01-09 18:17 ` Randy Witt
2017-01-06 9:55 ` [PATCH 3/3] rm_work.bbclass: clean up sooner Patrick Ohly
2017-02-15 18:32 ` Martin Jansa
2017-02-16 10:26 ` Patrick Ohly [this message]
2017-03-01 15:52 ` Martin Jansa
2017-03-01 16:44 ` Patrick Ohly
2017-03-01 18:47 ` Martin Jansa
2017-03-02 10:13 ` Patrick Ohly
2017-03-02 9:38 ` Patrick Ohly
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=1487240814.13854.449.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=martin.jansa@gmail.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 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.