linux/poky.git/bitbake/lib/bb/runqueue.py, branch 2.8_M3

bitbake: runqueue: validate_hashes(): currentcount should be a number

2019-09-19T19:30:35+00:00

According to sstate_checkhashes which is defined in sstate.bbclass, the currentcoun should be a number (0, not None). Fixed: $ bitbake base-files -Sprintdiff > bb.plain("Sstate summary: Wanted %d Found %d Missed %d Current %d (%d%% match, %d%% complete)" % (total, len(found), len(missed), currentcount, match, complete)) TypeError: %d format: a number is required, not NoneType (Bitbake rev: 45cb73e2846eaffe8964a573875f54808e8f3633) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bitbake: bitbake: Rework hash equivalence

2019-09-18T16:52:01+00:00

Reworks the hash equivalence server to address performance issues that were encountered with the REST mechanism used previously, particularly during the heavy request load encountered during signature generation. Notable changes are: 1) The server protocol is no longer HTTP based. Instead, it uses a simpler JSON over a streaming protocol link. This protocol has much lower overhead than HTTP since it eliminates the HTTP headers. 2) The hash equivalence server can either bind to a TCP port, or a Unix domain socket. Unix domain sockets are more efficient for local communication, and so are preferred if the user enables hash equivalence only for the local build. The arguments to the 'bitbake-hashserve' command have been updated accordingly. 3) The value to which BB_HASHSERVE should be set to enable a local hash equivalence server is changed to "auto" instead of "localhost:0". The latter didn't make sense when the local server was using a Unix domain socket. 4) Clients are expected to keep a persistent connection to the server instead of creating a new connection each time a request is made for optimal performance. 5) Most of the client logic has been moved to the hashserve module in bitbake. This makes it easier to share the client code. 6) A new bitbake command has been added called 'bitbake-hashclient'. This command can be used to query a hash equivalence server, including fetching the statistics and running a performance stress test. 7) The table indexes in the SQLite database have been updated to optimize hash lookups. This change is backward compatible, as the database will delete the old indexes first if they exist. 8) The server has been reworked to use python async to maximize performance with persistently connected clients. This requires Python 3.5 or later. (Bitbake rev: 2124eec3a5830afe8e07ffb6f2a0df6a417ac973) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: runqueue/siggen: Optimise hash equiv queries

2019-09-16T22:02:45+00:00

We only have hash equivalence for setscene tasks so only query the server for those, reducing the number of connections needed. (Bitbake rev: 22082c7b3ca0cffcedb7d1d8c6681d35286376db) Signed-off-by: Richard Purdie

bitbake: bitbake: respect force flag in runall and runonly

2019-08-28T15:44:09+00:00

Specifying the force flag will now cause runall and runonly to invalidate the tasks before running them. This allows a --runall or --runonly to force the tasks to run, even if they would have otherwise been skipped, e.g.: bitbake -f --runall fetch Will run all do_fetch tasks even if they wouldn't be necessary (for example, skipped by setscene) (Bitbake rev: 71e52d3822016027106f2a2e74b8dfdf20f5dc1e) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: runqueue: Optimise build_taskdepdata slightly

2019-08-21T14:30:13+00:00

Rather than repeatedly calling mc_from_tid() do this in the parent, removing around a million function calls. Takes time spent in this function from 40s to 36s. (Bitbake rev: 28b3f0d8867804799420689c314ac4a8f01efb8c) Signed-off-by: Richard Purdie

bitbake: runqueue: Further optimise holdoff tasks

2019-08-21T14:30:13+00:00

There are other data structures which can be reprocessed at the same time as holdoff_tasks, further improving build efficiency in various places. (Bitbake rev: 02090b3456b7a2de12e72dfeaabfd3b631609924) Signed-off-by: Richard Purdie

bitbake: runqueue: Optimise holdoff task handling

2019-08-21T14:30:13+00:00

We don't need to process the holdoff task list until we're executing tasks which saves some data manipulation, at the cost of some data structures not being correct at all times. This saves significant amounts of time in various profile charts of larger builds. (Bitbake rev: 270f076111b12eab358417b0c4cf9c70d7cc787a) Signed-off-by: Richard Purdie

bitbake: runqueue: Small but critical fix

2019-08-21T14:30:13+00:00

We've observed do_package and do_package_setscene running in parallel. The reason is that holdoff_tasks wasn't getting updated. Looking at the code, it would seem the reason is that the task was in pending_migrations and hence changed wasn't set and holdoff_tasks wasn't updated. Fix this. It only affects builds with rehashing enabled. (Bitbake rev: e26e61e84575669bd223f6ab316798097ed95ec8) Signed-off-by: Richard Purdie

bitbake: runqueue: Ensure target_tids is filtered

2019-08-16T09:05:33+00:00

bitbake --runonly=fetch failed as the target_tids list included entries which were no longer targeted task ids. Fix this. (Bitbake rev: 94e848ae6544e628a19cb97115279b0b1678967c) Signed-off-by: Richard Purdie

bitbake: runqueue: Ensure data is handled correctly

2019-08-15T12:32:06+00:00

This doesn't appear to have ill effects right now but there is a correctness issue which this so fix it. (Bitbake rev: a5e084a266f63c2fd370122327615e49beaeb94e) Signed-off-by: Richard Purdie