All of lore.kernel.org
 help / color / mirror / Atom feed
* Bitbake runqueue performance improvement
@ 2009-07-21 18:32 Richard Purdie
  2009-07-21 21:49 ` [Bitbake-dev] " Richard Purdie
  0 siblings, 1 reply; 19+ messages in thread
From: Richard Purdie @ 2009-07-21 18:32 UTC (permalink / raw)
  To: bitbake-dev; +Cc: openembedded-devel

At present there is a bottleneck in runqueue in the
get_recursive_tdepends() function which bothers me as we never used to
have it. It appeared when we fixed some correctness issues with the
dependency tree and the code in this area has grown adhoc for too long.

As an example the above function was getting called 500,000 times in my
main test case of building an image. Its particularly problematic in
builds with many recursive dependencies such as 'bitbake world'.

The attached patch rewrites the problematic function entirely with the
following benefits:

* Replaces the most illegible code in that function with code thats 
  easier to understand
* Builds the dependency tree per filename, not per task since we don't 
  need it per task which is a performance win
* Improves the documentation in places
* Much faster execution
* Reuses the main dependency tree data, doesn't make its own.

The code functions very differently to the original. Previously the
recursive dependency tree and the main dependency tree were separate. In
this implementation we use the main tree to build the recursive tree
after the main tree has been completed, then inject the dependencies.

Compared with the original this actually inserts small numbers (4 in my
test cases) of additional dependencies into the task graph such as
image_recipe:do_rootfs -> image_recipe:do_package_write_ipk which is
arguably an bug in the existing implementation. I've checked into this,
understand why its happening and believe none of the additional
dependencies should cause any complications.

Since this is critical code I'd appreciate any testing people can give
it.

Cheers,

Richard

diff --git a/bitbake/lib/bb/runqueue.py b/bitbake/lib/bb/runqueue.py
index 9b3cbdf..4c466b6 100644
--- a/bitbake/lib/bb/runqueue.py
+++ b/bitbake/lib/bb/runqueue.py
@@ -321,9 +321,10 @@ class RunQueue:
         to optimise the execution order.
         """
 
-        depends = []
         runq_build = []
         recursive_tdepends = {}
+        runq_recrdepends = []
+        tdepends_fnid = {}
 
         taskData = self.taskData
 
@@ -335,9 +336,9 @@ class RunQueue:
 
         # Step A - Work out a list of tasks to run
         #
-        # Taskdata gives us a list of possible providers for a every target 
-        # ordered by priority (build_targets, run_targets). It also gives
-        # information on each of those providers.
+        # Taskdata gives us a list of possible providers for every build and run
+        # target ordered by priority. It also gives information on each of those 
+        # providers.
         #
         # To create the actual list of tasks to execute we fix the list of 
         # providers and then resolve the dependencies into task IDs. This 
@@ -345,10 +346,14 @@ class RunQueue:
         # rdeptast, recrdeptask, idepends).
 
         for task in range(len(taskData.tasks_name)):
+            depends = []
+            recrdepends = []
             fnid = taskData.tasks_fnid[task]
             fn = taskData.fn_index[fnid]
             task_deps = self.dataCache.task_deps[fn]
 
+            bb.msg.debug(2, bb.msg.domain.RunQueue, "Processing %s:%s" %(fn, taskData.tasks_name[task]))
+
             if fnid not in taskData.failed_fnids:
 
                 # Resolve task internal dependencies 
@@ -388,6 +393,8 @@ class RunQueue:
                 #
                 # e.g. do_sometask[depends] = "targetname:do_someothertask"
                 # (makes sure sometask runs after targetname's someothertask)
+                if fnid not in tdepends_fnid:
+                    tdepends_fnid[fnid] = set()
                 idepends = taskData.tasks_idepends[task]
                 for (depid, idependtask) in idepends:
                     if depid in taskData.build_targets:
@@ -395,122 +402,37 @@ class RunQueue:
                         depdata = taskData.build_targets[depid][0]
                         if depdata is not None:
                             dep = taskData.fn_index[depdata]
-                            depends.append(taskData.gettask_id(dep, idependtask))
-
-                # Create a list of recursive dependent tasks (from tdepends) and cache
-                def get_recursive_tdepends(task):
-                    if not task:
-                        return []
-                    if task in recursive_tdepends:
-                        return recursive_tdepends[task]
-
-                    fnid = taskData.tasks_fnid[task]
-                    taskids = taskData.gettask_ids(fnid)
-
-                    rectdepends = taskids
-                    nextdeps = taskids
-                    while len(nextdeps) != 0:
-                        newdeps = []
-                        for nextdep in nextdeps:
-                            for tdepend in taskData.tasks_tdepends[nextdep]:
-                                if tdepend not in rectdepends:
-                                    rectdepends.append(tdepend)
-                                    newdeps.append(tdepend)
-                        nextdeps = newdeps
-                    recursive_tdepends[task] = rectdepends
-                    return rectdepends
-
-                # Using the list of tdepends for this task create a list of 
-                # the recursive idepends we have
-                def get_recursive_idepends(task):
-                    if not task:
-                        return []
-                    rectdepends = get_recursive_tdepends(task)
-
-                    recidepends = []
-                    for tdepend in rectdepends:
-                        for idepend in taskData.tasks_idepends[tdepend]:
-                            recidepends.append(idepend)
-                    return recidepends
-
-                def add_recursive_build(depid, depfnid):
-                    """
-                    Add build depends of depid to depends
-                    (if we've not see it before)
-                    (calls itself recursively)
-                    """
-                    if str(depid) in dep_seen:
-                        return
-                    dep_seen.append(depid)
-                    if depid in taskData.build_targets:
-                        depdata = taskData.build_targets[depid][0]
-                        if depdata is not None:
-                            dep = taskData.fn_index[depdata]
-                            # Need to avoid creating new tasks here
-                            taskid = taskData.gettask_id(dep, taskname, False)
-                            if taskid is not None:
-                                depends.append(taskid)
-                                fnid = taskData.tasks_fnid[taskid]
-                                #print "Added %s (%s) due to %s" % (taskid, taskData.fn_index[fnid], taskData.fn_index[depfnid])
-                            else:
-                                fnid = taskData.getfn_id(dep)
-                            for nextdepid in taskData.depids[fnid]:
-                                if nextdepid not in dep_seen:
-                                    add_recursive_build(nextdepid, fnid)
-                            for nextdepid in taskData.rdepids[fnid]:
-                                if nextdepid not in rdep_seen:
-                                    add_recursive_run(nextdepid, fnid)
-                            for (idependid, idependtask) in get_recursive_idepends(taskid):
-                                if idependid not in dep_seen:
-                                    add_recursive_build(idependid, fnid)
-
-                def add_recursive_run(rdepid, depfnid):
-                    """
-                    Add runtime depends of rdepid to depends
-                    (if we've not see it before)
-                    (calls itself recursively)
-                    """
-                    if str(rdepid) in rdep_seen:
-                        return
-                    rdep_seen.append(rdepid)
-                    if rdepid in taskData.run_targets:
-                        depdata = taskData.run_targets[rdepid][0]
-                        if depdata is not None:
-                            dep = taskData.fn_index[depdata]
-                            # Need to avoid creating new tasks here
-                            taskid = taskData.gettask_id(dep, taskname, False)
-                            if taskid is not None:
-                                depends.append(taskid)
-                                fnid = taskData.tasks_fnid[taskid]
-                                #print "Added %s (%s) due to %s" % (taskid, taskData.fn_index[fnid], taskData.fn_index[depfnid])
-                            else:
-                                fnid = taskData.getfn_id(dep)
-                            for nextdepid in taskData.depids[fnid]:
-                                if nextdepid not in dep_seen:
-                                    add_recursive_build(nextdepid, fnid)
-                            for nextdepid in taskData.rdepids[fnid]:
-                                if nextdepid not in rdep_seen:
-                                    add_recursive_run(nextdepid, fnid)
-                            for (idependid, idependtask) in get_recursive_idepends(taskid):
-                                if idependid not in dep_seen:
-                                    add_recursive_build(idependid, fnid)
-
-                # Resolve recursive 'recrdeptask' dependencies 
+                            taskid = taskData.gettask_id(dep, idependtask)
+                            depends.append(taskid)
+                            if depdata != fnid:
+                                tdepends_fnid[fnid].add(taskid)
+
+
+                # Resolve recursive 'recrdeptask' dependencies (A)
                 #
                 # e.g. do_sometask[recrdeptask] = "do_someothertask"
                 # (makes sure sometask runs after someothertask of all DEPENDS, RDEPENDS and intertask dependencies, recursively)
+                # We cover the recursive part of the dependencies below
                 if 'recrdeptask' in task_deps and taskData.tasks_name[task] in task_deps['recrdeptask']:
                     for taskname in task_deps['recrdeptask'][taskData.tasks_name[task]].split():
-                        dep_seen = []
-                        rdep_seen = []
-                        idep_seen = []
+                        recrdepends.append(taskname)
+                        for depid in taskData.rdepids[fnid]:
+                            if depid in taskData.run_targets:
+                                depdata = taskData.run_targets[depid][0]
+                                if depdata is not None:
+                                    dep = taskData.fn_index[depdata]
+                                    taskid = taskData.gettask_id(dep, taskname, False)
+                                    if taskid is not None:
+                                        depends.append(taskid)
                         for depid in taskData.depids[fnid]:
-                            add_recursive_build(depid, fnid)
-                        for rdepid in taskData.rdepids[fnid]:
-                            add_recursive_run(rdepid, fnid)
-                        deptaskid = taskData.gettask_id(fn, taskname, False)
-                        for (idependid, idependtask) in get_recursive_idepends(deptaskid):
-                            add_recursive_build(idependid, fnid)
+                            # Won't be in build_targets if ASSUME_PROVIDED
+                            if depid in taskData.build_targets:
+                                depdata = taskData.build_targets[depid][0]
+                                if depdata is not None:
+                                    dep = taskData.fn_index[depdata]
+                                    taskid = taskData.gettask_id(dep, taskname, False)
+                                    if taskid is not None:
+                                        depends.append(taskid)
 
                 # Rmove all self references
                 if task in depends:
@@ -521,13 +443,51 @@ class RunQueue:
                           newdep.append(dep)
                     depends = newdep
 
-
             self.runq_fnid.append(taskData.tasks_fnid[task])
             self.runq_task.append(taskData.tasks_name[task])
             self.runq_depends.append(set(depends))
             self.runq_revdeps.append(set())
 
             runq_build.append(0)
+            runq_recrdepends.append(recrdepends)
+
+        #
+        # Build a list of recursive cumulative dependencies for each fnid
+        # We do this by fnid, since if A depends on some task in B
+        # we're interested in later tasks B's fnid might have but B itself 
+        # doesn't depend on
+        #
+        # Algorithm is O(tasks) + O(tasks)*O(fnids)
+        #
+        reccumdepends = {}
+        for task in range(len(self.runq_fnid)):
+            fnid = self.runq_fnid[task]
+            if fnid not in reccumdepends:
+                reccumdepends[fnid] = set()
+            if task in self.runq_depends:
+                reccumdepends[fnid].update(self.runq_depends[task])
+            if fnid in tdepends_fnid:
+                reccumdepends[fnid].update(tdepends_fnid[fnid])
+        for task in range(len(self.runq_fnid)):
+            taskfnid = self.runq_fnid[task]
+            for fnid in reccumdepends:
+                if task in reccumdepends[fnid]:
+                    reccumdepends[fnid].add(task)
+                    if taskfnid in reccumdepends:
+                        reccumdepends[fnid].update(reccumdepends[taskfnid])
+
+
+        # Resolve recursive 'recrdeptask' dependencies (B)
+        #
+        # e.g. do_sometask[recrdeptask] = "do_someothertask"
+        # (makes sure sometask runs after someothertask of all DEPENDS, RDEPENDS and intertask dependencies, recursively)
+        for task in range(len(self.runq_fnid)):
+            if len(runq_recrdepends[task]) > 0:
+                taskfnid = self.runq_fnid[task]
+                for dep in reccumdepends[taskfnid]:
+                    for taskname in runq_recrdepends[task]:
+                        if taskData.tasks_name[dep] == taskname:
+                            self.runq_depends[task].add(dep)
 
         # Step B - Mark all active tasks
         #



-- 
Richard Purdie
Intel Open Source Technology Centre




^ permalink raw reply related	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-21 18:32 Bitbake runqueue performance improvement Richard Purdie
@ 2009-07-21 21:49 ` Richard Purdie
  2009-07-21 22:58   ` Michael Smith
  0 siblings, 1 reply; 19+ messages in thread
From: Richard Purdie @ 2009-07-21 21:49 UTC (permalink / raw)
  To: bitbake-dev; +Cc: openembedded-devel

On Tue, 2009-07-21 at 19:32 +0100, Richard Purdie wrote:
> The attached patch rewrites the problematic function entirely with the
> following benefits:

Of course one of my last minute cosmetic cleanups broke it :(.

http://git.pokylinux.org/cgit.cgi/poky/commit/?id=502bd2ef92f6cddf74ac85279dab621372791dc0 is the key fix with a couple of other things I noticed too.

Cheers,

Richard

-- 
Richard Purdie
Intel Open Source Technology Centre




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-21 21:49 ` [Bitbake-dev] " Richard Purdie
@ 2009-07-21 22:58   ` Michael Smith
  2009-07-22  1:43     ` Chris Larson
  2009-07-22  8:53     ` Richard Purdie
  0 siblings, 2 replies; 19+ messages in thread
From: Michael Smith @ 2009-07-21 22:58 UTC (permalink / raw)
  To: bitbake-dev; +Cc: openembedded-devel

Richard Purdie wrote:
> On Tue, 2009-07-21 at 19:32 +0100, Richard Purdie wrote:
>> The attached patch rewrites the problematic function entirely with the
>> following benefits:
> 
> Of course one of my last minute cosmetic cleanups broke it :(.
> 
> http://git.pokylinux.org/cgit.cgi/poky/commit/?id=502bd2ef92f6cddf74ac85279dab621372791dc0 is the key fix with a couple of other things I noticed too.

Hi Richard,

I've been playing around with this and it seems to be creating some 
problems, unless it's just finding problems in my overlay that the old 
code didn't see.

With the latest fix, it finds dependency loops, but I'm not sure how to 
track them down as the dependencies are identified only by numbers:

NOTE: Preparing runqueue
ERROR: Unbuildable tasks were found.
These are usually caused by circular dependencies and any circular 
dependency chains found will be printed below. Increase the debug level 
to see a list of unbuildable tasks.

Identifying dependency loops (this may take a short while)...

ERROR:
Dependency loop #1 found:
   Task 7 
(/home/michael/startitup/public/recipes/images/toastix-image.bb, 
do_install) (depends: set([9, 6]))
   Task 8 
(/home/michael/startitup/public/recipes/images/toastix-image.bb, 
do_populate_staging) (depends: set([7]))
   Task 9 
(/home/michael/startitup/public/recipes/images/toastix-image.bb, 
do_rootfs) (depends: set([1024, 6, 2049, 8, 2057, 2059, 13, 791, 2067, 
21, 23, 2077, 31, 33, 2087, 41, 43, 2097, 51, 53, 2107,

[snip a few hundred numbers]

Before the fix from 502bd2e, it was dropping some do_package_write_deb 
dependencies that are needed to ensure .debs are built for packages that 
are not listed in IMAGE_INSTALL, but are required by other packages. My 
task-depends.dot was missing about 1000 entries. So was my depends.dot.

For example, I've got openssh in my IMAGE_INSTALL and it DEPENDS on zlib 
(and has a run-time dependency via shlibs). If I removed my zlib debs 
and tmp/stamps/blah/zlib-1.2.3-r5.do_package*, building my image should 
have built the zlib debs (and did before applying your patches), but it 
didn't so the rootfs failed.


BTW, is there any chance of getting Bitbake officially moved to a Git 
repo? I think a few people are working out of git-svn trees, or subdirs 
inside larger git trees, but it takes some gymnastics to merge between 
them as Git doesn't know they're related.

Thanks,
Mike



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-21 22:58   ` Michael Smith
@ 2009-07-22  1:43     ` Chris Larson
  2009-07-22  8:53     ` Richard Purdie
  1 sibling, 0 replies; 19+ messages in thread
From: Chris Larson @ 2009-07-22  1:43 UTC (permalink / raw)
  To: Michael Smith; +Cc: openembedded-devel, bitbake-dev

On Tue, Jul 21, 2009 at 3:58 PM, Michael Smith<msmith@cbnco.com> wrote:
> BTW, is there any chance of getting Bitbake officially moved to a Git
> repo? I think a few people are working out of git-svn trees, or subdirs
> inside larger git trees, but it takes some gymnastics to merge between
> them as Git doesn't know they're related.

I'm working on that now, Mike.  I have my current version at
http://github.com/kergoth/BitBake/ -
git://github.com/kergoth/BitBake.git.  It is 1) old bkcvs history, 2)
pre-reorg layout on the svn, 3) post-reorg layout on the svn, with the
OE metadata history mostly ripped out, as well as the old test recipes
and stuff, so its down to just bitbake.  There are still some minor
annoyances in commit log message formatting, but those are difficult
to fix automatically, and are generally cosmetic, so I think I won't
bother with those.  If this repo seems sane to people, we can see
about getting it onto the OE git server.

-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-21 22:58   ` Michael Smith
  2009-07-22  1:43     ` Chris Larson
@ 2009-07-22  8:53     ` Richard Purdie
  2009-07-22 13:13       ` Michael Smith
  1 sibling, 1 reply; 19+ messages in thread
From: Richard Purdie @ 2009-07-22  8:53 UTC (permalink / raw)
  To: openembedded-devel; +Cc: bitbake-dev

On Tue, 2009-07-21 at 18:58 -0400, Michael Smith wrote:
> I've been playing around with this and it seems to be creating some 
> problems, unless it's just finding problems in my overlay that the old 
> code didn't see.
> 
> With the latest fix, it finds dependency loops, but I'm not sure how to 
> track them down as the dependencies are identified only by numbers:

Thanks for testing. It is actually telling you the problem and decoding
the information:

> Dependency loop #1 found:
>    Task 7 
> (/home/michael/startitup/public/recipes/images/toastix-image.bb, 
> do_install) (depends: set([9, 6]))
>    Task 8 
> (/home/michael/startitup/public/recipes/images/toastix-image.bb, 
> do_populate_staging) (depends: set([7]))
>    Task 9 
> (/home/michael/startitup/public/recipes/images/toastix-image.bb, 
> do_rootfs) (depends: set([1024, 6, 2049, 8, 2057, 2059, 13, 791, 2067, 
> 21, 23, 2077, 31, 33, 2087, 41, 43, 2097, 51, 53, 2107,

So task 7 depends on task 9 which depends on task 8 which depends on
task 7. Its lists what tasks 7, 8 and 9 are.

Is it just this image recipe thats causing problems or are there others?
Can you point me at a copy of the recipe?

> Before the fix from 502bd2e, it was dropping some do_package_write_deb 
> dependencies that are needed to ensure .debs are built for packages that 
> are not listed in IMAGE_INSTALL, but are required by other packages. My 
> task-depends.dot was missing about 1000 entries. So was my depends.dot.

Yes, without the fix it would do that.

> BTW, is there any chance of getting Bitbake officially moved to a Git 
> repo? I think a few people are working out of git-svn trees, or subdirs 
> inside larger git trees, but it takes some gymnastics to merge between 
> them as Git doesn't know they're related.

As Chris replied, he's looking at this. I admit I'd like to see bitbake
moved to git.

Cheers,

Richard

-- 
Richard Purdie
Intel Open Source Technology Centre




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-22  8:53     ` Richard Purdie
@ 2009-07-22 13:13       ` Michael Smith
  2009-07-22 22:24         ` Richard Purdie
  0 siblings, 1 reply; 19+ messages in thread
From: Michael Smith @ 2009-07-22 13:13 UTC (permalink / raw)
  To: openembedded-devel; +Cc: bitbake-dev

On Wed, 22 Jul 2009, Richard Purdie wrote:

> On Tue, 2009-07-21 at 18:58 -0400, Michael Smith wrote:

> So task 7 depends on task 9 which depends on task 8 which depends on
> task 7. Its lists what tasks 7, 8 and 9 are.

Ah. Sorry, router exploded, broke brain. The loop message is fairly self 
explanatory, now that I actually read it.

I get a similar problem with micro-image:

Dependency loop #1 found:
  Task 7 (/home/michael/git/toastix/oe/recipes/images/micro-image.bb, 
do_install) (depends: set([9, 6]))
  Task 8 (/home/michael/git/toastix/oe/recipes/images/micro-image.bb, 
do_populate_staging) (depends: set([7]))   
  Task 9 (/home/michael/git/toastix/oe/recipes/images/micro-image.bb, 
do_rootfs) (depends: set([385, 387, 133, 6, 135, 8, 265, 13, [...]

Dependency loop #2 found:
  Task 7 (/home/michael/git/toastix/oe/recipes/images/micro-image.bb, 
do_install) (depends: set([9, 6]))
  Task 11 (/home/michael/git/toastix/oe/recipes/images/micro-image.bb, 
do_package) (depends: set([7]))
  Task 13 (/home/michael/git/toastix/oe/recipes/images/micro-image.bb, 
do_package_write_deb) (depends: set([11]))
  Task 9 (/home/michael/git/toastix/oe/recipes/images/micro-image.bb, 
do_rootfs) (depends: set([385, 387, 133, 6, 135, 8, 265, 13, [...]


Before the patch, I have dependencies for

<image>.do_package -> <image>.do_install -> <image>.do_rootfs

Also, <image>.do_package_write_deb -> <image>.do_package.

At the top of the thread you wrote about extra dependecies being 
introduced (<image>.do_rootfs -> <image>.do_package_write_ipk, or 
write_deb in my case). I think this is what creates the loop.

I can get you instructions for building with the overlay if you like -- 
contact me off list if you're interested.

Mike



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-22 13:13       ` Michael Smith
@ 2009-07-22 22:24         ` Richard Purdie
  2009-07-23  5:48           ` Roman I Khimov
  0 siblings, 1 reply; 19+ messages in thread
From: Richard Purdie @ 2009-07-22 22:24 UTC (permalink / raw)
  To: openembedded-devel; +Cc: bitbake-dev

So I looked into this offlist. The problem is actually OE's
image.bbclass which has:

"addtask rootfs after do_compile before do_install"

introduced in:

http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=736c06e8d8efa79d3d2bc512f13a51f0f63412e2

Our rootfs_ipk class has:

do_rootfs[recrdeptask] += "do_package_write_ipk"

which means do_rootfs runs after every do_package_write_ipk task that
do_rootfs can recursively depend on.

do_package_write_ipk depends on do_package which depends on do_install.

The image.bb file itself actually has a do_package_write_ipk task just
like any other .bb file and do_rootfs should come after it yet we insert
it before do_install.

So what I'm saying is that I think the new bitbake code has found a
valid error in the metadata and that commit is rather misguided.
Multiple image generation works fine in Poky without that FWIW too.

Does anyone have any thoughts?

Cheers,

Richard





^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-22 22:24         ` Richard Purdie
@ 2009-07-23  5:48           ` Roman I Khimov
  2009-07-23  8:04             ` Richard Purdie
  0 siblings, 1 reply; 19+ messages in thread
From: Roman I Khimov @ 2009-07-23  5:48 UTC (permalink / raw)
  To: openembedded-devel

On Четверг 23 июля 2009 02:24:33 Richard Purdie wrote:
> Our rootfs_ipk class has:
>
> do_rootfs[recrdeptask] += "do_package_write_ipk"
>
> which means do_rootfs runs after every do_package_write_ipk task that
> do_rootfs can recursively depend on.
>
> do_package_write_ipk depends on do_package which depends on do_install.
>
> The image.bb file itself actually has a do_package_write_ipk task just
> like any other .bb file and do_rootfs should come after it yet we insert
> it before do_install.

If recrdeptask is supposed to apply to the package that wants recrdeps, then 
it's wrong, sure. How to fix that is the question, we can't do

do_rootfs[recrdeptask] += "do_rootfs"

And yet we want to run do_rootfs for image after do_rootfs's for dependencies 
were made.

> Multiple image generation works fine in Poky without that FWIW too.

It can't or we're talking about different multiimage situations. I've written 
already here, suppose you need different images that depend like this (real 
example, BTW):

       /-8
  /-2--+
1-+    +-9
  |    |
  +-3  \-10
  |
  +-4
  |
  \-5-6-7

So when I'm building image number 2, I need to have images 8, 9, 10 to be 
built to place that images on image number 2. Same with 6-7, 5-6 and 1 to 2, 
3, 4, 5. Without that patch bitbake started do_rootfs for image number 2 
before do_rootfs for 8, 9, 10 was done.

In order to solve it using standard package deps mechanism that commit was 
made.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-23  5:48           ` Roman I Khimov
@ 2009-07-23  8:04             ` Richard Purdie
  2009-07-23  8:46               ` Roman I Khimov
  0 siblings, 1 reply; 19+ messages in thread
From: Richard Purdie @ 2009-07-23  8:04 UTC (permalink / raw)
  To: openembedded-devel

On Thu, 2009-07-23 at 09:48 +0400, Roman I Khimov wrote:
> If recrdeptask is supposed to apply to the package that wants recrdeps, then 
> it's wrong, sure. How to fix that is the question, we can't do
> 
> do_rootfs[recrdeptask] += "do_rootfs"
> 
> And yet we want to run do_rootfs for image after do_rootfs's for dependencies 
> were made.

Ok, I understand what you're trying to solve.

> It can't or we're talking about different multiimage situations.

It does work and its not really so different. For example:

http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/images/poky-image-live.inc

>  I've written 
> already here, suppose you need different images that depend like this (real 
> example, BTW):
> 
>        /-8
>   /-2--+
> 1-+    +-9
>   |    |
>   +-3  \-10
>   |
>   +-4
>   |
>   \-5-6-7
> 
> So when I'm building image number 2, I need to have images 8, 9, 10 to be 
> built to place that images on image number 2. Same with 6-7, 5-6 and 1 to 2, 
> 3, 4, 5. Without that patch bitbake started do_rootfs for image number 2 
> before do_rootfs for 8, 9, 10 was done.
> 
> In order to solve it using standard package deps mechanism that commit was 
> made.

Images 1,2,5 and 6 need to specify they have dependencies on other image
rootfs tasks with something like:

do_rootfs[depends] += "some-other-image-task:do_rootfs"

Is there some reason this doesn't work?

Cheers,

Richard





^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-23  8:04             ` Richard Purdie
@ 2009-07-23  8:46               ` Roman I Khimov
  2009-07-23 12:19                 ` Richard Purdie
  0 siblings, 1 reply; 19+ messages in thread
From: Roman I Khimov @ 2009-07-23  8:46 UTC (permalink / raw)
  To: openembedded-devel

On Четверг 23 июля 2009 12:04:51 Richard Purdie wrote:
> On Thu, 2009-07-23 at 09:48 +0400, Roman I Khimov wrote:
> >        /-8
> >   /-2--+
> > 1-+    +-9
> >
> >   +-3  \-10
> >
> >   +-4
> >
> >   \-5-6-7
>
> Images 1,2,5 and 6 need to specify they have dependencies on other image
> rootfs tasks with something like:
>
> do_rootfs[depends] += "some-other-image-task:do_rootfs"
>
> Is there some reason this doesn't work?

Well, that would work, obviously, but seemed like a bad style to me, we have 
DEPENDS for recipe dependencies, so why images should be that different? And 
in my case it would be

do_rootfs[depends] += "image2:do_rootfs image3:do_rootfs image4:do_rootfs \
	image5:do_rootfs"

compared to

DEPENDS += "image2 image3 image4 image5"

which worked well for quite some time.

If there is any way to keep this DEPENDS behaviour?



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-23  8:46               ` Roman I Khimov
@ 2009-07-23 12:19                 ` Richard Purdie
  2009-07-23 13:05                   ` Holger Hans Peter Freyther
  2009-07-23 17:41                   ` Roman I Khimov
  0 siblings, 2 replies; 19+ messages in thread
From: Richard Purdie @ 2009-07-23 12:19 UTC (permalink / raw)
  To: openembedded-devel

On Thu, 2009-07-23 at 12:46 +0400, Roman I Khimov wrote:
> On Четверг 23 июля 2009 12:04:51 Richard Purdie wrote:
> > do_rootfs[depends] += "some-other-image-task:do_rootfs"
> >
> > Is there some reason this doesn't work?
> 
> Well, that would work, obviously, but seemed like a bad style to me, we have 
> DEPENDS for recipe dependencies, so why images should be that different? And 
> in my case it would be
> 
> do_rootfs[depends] += "image2:do_rootfs image3:do_rootfs image4:do_rootfs \
> 	image5:do_rootfs"
> 
> compared to
> 
> DEPENDS += "image2 image3 image4 image5"
> 
> which worked well for quite some time.
> 
> If there is any way to keep this DEPENDS behaviour?

DEPENDS is defined to mean that everything listed there must have
completed its staging task (do_populate_staging) before the recipe in
question's configure task has run.

Its a shorthand for creating dependencies of the most common kind and
you are overloading it with something with a different meaning which
just happens to work if you fudge things in the right places.

The whole point is that we want the dependencies to be clear. Your
approach is anything but clear IMO.

Also note that DEPENDS only gets its magical meaning from the entry in
base.bbclass which says:

do_configure[deptask] = "do_populate_staging"

and these forms are what bitbake actually works with, not the shorthand
convenience forms of DEPENDS and RDEPENDS.

Cheers,

Richard




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-23 12:19                 ` Richard Purdie
@ 2009-07-23 13:05                   ` Holger Hans Peter Freyther
  2009-07-23 17:41                   ` Roman I Khimov
  1 sibling, 0 replies; 19+ messages in thread
From: Holger Hans Peter Freyther @ 2009-07-23 13:05 UTC (permalink / raw)
  To: openembedded-devel

On Thursday 23 July 2009 14:19:56 Richard Purdie wrote:
> On Thu, 2009-07-23 at 12:46 +0400, Roman I Khimov wrote:

> Also note that DEPENDS only gets its magical meaning from the entry in
> base.bbclass which says:
>
> do_configure[deptask] = "do_populate_staging"
>
> and these forms are what bitbake actually works with, not the shorthand
> convenience forms of DEPENDS and RDEPENDS.

I agree with Richard that the mentioned commit should be reverted and that 
inter rootfs dependencies need to be handled with task dependencies[1].

love
	z.


[1] given the current bitbake implementation



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-23 12:19                 ` Richard Purdie
  2009-07-23 13:05                   ` Holger Hans Peter Freyther
@ 2009-07-23 17:41                   ` Roman I Khimov
  2009-07-23 22:03                     ` Richard Purdie
  1 sibling, 1 reply; 19+ messages in thread
From: Roman I Khimov @ 2009-07-23 17:41 UTC (permalink / raw)
  To: openembedded-devel

On Четверг 23 июля 2009 16:19:56 Richard Purdie wrote:
> The whole point is that we want the dependencies to be clear. Your
> approach is anything but clear IMO.

Well, using DEPENDS for dependencies still looks way better to me, but feel 
free to revert it.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-23 17:41                   ` Roman I Khimov
@ 2009-07-23 22:03                     ` Richard Purdie
  2009-07-24  5:00                       ` Roman I Khimov
  0 siblings, 1 reply; 19+ messages in thread
From: Richard Purdie @ 2009-07-23 22:03 UTC (permalink / raw)
  To: openembedded-devel

On Thu, 2009-07-23 at 21:41 +0400, Roman I Khimov wrote:
> On Четверг 23 июля 2009 16:19:56 Richard Purdie wrote:
> > The whole point is that we want the dependencies to be clear. Your
> > approach is anything but clear IMO.
> 
> Well, using DEPENDS for dependencies still looks way better to me, but feel 
> free to revert it.

Are there recipes in OE which need fixing prior to that happening?

Cheers,

Richard




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-23 22:03                     ` Richard Purdie
@ 2009-07-24  5:00                       ` Roman I Khimov
  2009-07-24 16:49                         ` Richard Purdie
  0 siblings, 1 reply; 19+ messages in thread
From: Roman I Khimov @ 2009-07-24  5:00 UTC (permalink / raw)
  To: openembedded-devel

On Пятница 24 июля 2009 02:03:35 Richard Purdie wrote:
> On Thu, 2009-07-23 at 21:41 +0400, Roman I Khimov wrote:
> > On Четверг 23 июля 2009 16:19:56 Richard Purdie wrote:
> > > The whole point is that we want the dependencies to be clear. Your
> > > approach is anything but clear IMO.
> >
> > Well, using DEPENDS for dependencies still looks way better to me, but
> > feel free to revert it.
>
> Are there recipes in OE which need fixing prior to that happening?

I don't think so, at least I've not pushed any inter-image dependencies via 
DEPENDS myself.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-24  5:00                       ` Roman I Khimov
@ 2009-07-24 16:49                         ` Richard Purdie
  2009-07-24 17:37                           ` Michael Smith
  0 siblings, 1 reply; 19+ messages in thread
From: Richard Purdie @ 2009-07-24 16:49 UTC (permalink / raw)
  To: openembedded-devel

On Fri, 2009-07-24 at 09:00 +0400, Roman I Khimov wrote:
> On Пятница 24 июля 2009 02:03:35 Richard Purdie wrote:
> > On Thu, 2009-07-23 at 21:41 +0400, Roman I Khimov wrote:
> > > On Четверг 23 июля 2009 16:19:56 Richard Purdie wrote:
> > > > The whole point is that we want the dependencies to be clear. Your
> > > > approach is anything but clear IMO.
> > >
> > > Well, using DEPENDS for dependencies still looks way better to me, but
> > > feel free to revert it.
> >
> > Are there recipes in OE which need fixing prior to that happening?
> 
> I don't think so, at least I've not pushed any inter-image dependencies via 
> DEPENDS myself.

Ok, I've committed a revert of that patch.

Is there any other feedback on the bitbake patch?

Cheers,

Richard




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-24 16:49                         ` Richard Purdie
@ 2009-07-24 17:37                           ` Michael Smith
  2009-07-24 21:11                             ` Richard Purdie
  0 siblings, 1 reply; 19+ messages in thread
From: Michael Smith @ 2009-07-24 17:37 UTC (permalink / raw)
  To: openembedded-devel

Richard Purdie wrote:

> Is there any other feedback on the bitbake patch?

For me, it makes preparing the runqueue at least twice as fast (from ~2 
to ~1 second for a small console image, ~14 to ~6 for something with X11).

My task dependencies look identical before and after the patch, except 
for the new harmless <image>.do_rootfs -> 
<image>.do_package_write_deb,do_populate_staging that you wrote about at 
the start of the thread.

Now if only "Resolving any missing task queue dependencies" were a 
little faster :) That part's running about 40 seconds for me on a large 
image.

Mike



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-24 17:37                           ` Michael Smith
@ 2009-07-24 21:11                             ` Richard Purdie
  2009-07-24 22:00                               ` Michael Smith
  0 siblings, 1 reply; 19+ messages in thread
From: Richard Purdie @ 2009-07-24 21:11 UTC (permalink / raw)
  To: openembedded-devel

On Fri, 2009-07-24 at 13:37 -0400, Michael Smith wrote:
> Richard Purdie wrote:
> 
> > Is there any other feedback on the bitbake patch?
> 
> For me, it makes preparing the runqueue at least twice as fast (from ~2 
> to ~1 second for a small console image, ~14 to ~6 for something with X11).

Great!

> My task dependencies look identical before and after the patch, except 
> for the new harmless <image>.do_rootfs -> 
> <image>.do_package_write_deb,do_populate_staging that you wrote about at 
> the start of the thread.
> 
> Now if only "Resolving any missing task queue dependencies" were a 
> little faster :) That part's running about 40 seconds for me on a large 
> image.

As it happens, try the patch from
http://cgit.openembedded.net/cgit.cgi/bitbake/commit/?id=72bf7476b2492b6524cb8ff87ee5f4e86b28d975

It should apply to bitbake 1.8 just as well as trunk as those files are
the same.

If anyone is interested in profiling things, "bitbake foo -g -P" gives
the numbers on where its spending time.

Cheers,

Richard




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Bitbake-dev] Bitbake runqueue performance improvement
  2009-07-24 21:11                             ` Richard Purdie
@ 2009-07-24 22:00                               ` Michael Smith
  0 siblings, 0 replies; 19+ messages in thread
From: Michael Smith @ 2009-07-24 22:00 UTC (permalink / raw)
  To: openembedded-devel

Richard Purdie wrote:
> On Fri, 2009-07-24 at 13:37 -0400, Michael Smith wrote:

>> Now if only "Resolving any missing task queue dependencies" were a 
>> little faster :) That part's running about 40 seconds for me on a large 
>> image.
> 
> As it happens, try the patch from
> http://cgit.openembedded.net/cgit.cgi/bitbake/commit/?id=72bf7476b2492b6524cb8ff87ee5f4e86b28d975
> 
> It should apply to bitbake 1.8 just as well as trunk as those files are
> the same.

Yes, it sure does... for a small image, the time was cut from 23 seconds 
to under 1 second. Thanks!

Mike



^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2009-07-24 22:15 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-21 18:32 Bitbake runqueue performance improvement Richard Purdie
2009-07-21 21:49 ` [Bitbake-dev] " Richard Purdie
2009-07-21 22:58   ` Michael Smith
2009-07-22  1:43     ` Chris Larson
2009-07-22  8:53     ` Richard Purdie
2009-07-22 13:13       ` Michael Smith
2009-07-22 22:24         ` Richard Purdie
2009-07-23  5:48           ` Roman I Khimov
2009-07-23  8:04             ` Richard Purdie
2009-07-23  8:46               ` Roman I Khimov
2009-07-23 12:19                 ` Richard Purdie
2009-07-23 13:05                   ` Holger Hans Peter Freyther
2009-07-23 17:41                   ` Roman I Khimov
2009-07-23 22:03                     ` Richard Purdie
2009-07-24  5:00                       ` Roman I Khimov
2009-07-24 16:49                         ` Richard Purdie
2009-07-24 17:37                           ` Michael Smith
2009-07-24 21:11                             ` Richard Purdie
2009-07-24 22:00                               ` Michael Smith

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.