Mirror of git.yoctoproject.org/poky https://git.enea.com/cgit/linux/poky.git/atom?h=3.1_M1 2019-12-12T14:21:35+00:00 2019-12-12T14:21:35+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2019-12-12T14:20:53+00:00 urn:sha1:39d45ef825694705daf6d7ab4ab3066b1b8e3aa2 This reverts commit c4b8440f730c33eaf9f818b856ae81b2f1017fec. The logic in this change is flawed and needs to be re-thought. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2019-12-12T13:15:00+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2019-12-11T23:11:50+00:00 urn:sha1:6b2cdc4b96eab7ad5e8ae8daebe24f2b18b09b1e We're seeing huge slowdowns on large builds on the autobuilder. A qemux86 world build was running really slowly, a primary feature was lots of rehashing going on due to an sstate change which caused a rebuild when all output should be identical. This was traced to the hundreds of thousands of calls to get_unihash() from get_taskash(). If we simplify the unitaskhashes data structure, we can bypass the function call and access the data directly. In local profile charts, this significanly sped up process_possible_migrations(), both on profiles and visually. Whilst this change doesn't aid readability, it does solve an otherwise huge performance issue. (Bitbake rev: c4b8440f730c33eaf9f818b856ae81b2f1017fec) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2019-12-09T17:29:49+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2019-12-09T17:28:38+00:00 urn:sha1:4f528b0bf3bfe26a26a72517baaae299b699bb0e Its possible the new unihash may not exist in sstate. Currently the code would create an sstate object with the old hash however this updates it to create the object with the new unihash. (Bitbake rev: abcaa1398031fa5338a43859c661e6d4a9ce863d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2019-12-06T14:39:29+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2019-12-05T15:26:56+00:00 urn:sha1:e10df257c9f1fdb63a8683f7aea80b0e5df896ca An example: NOTE: recipe binutils-cross-testsuite-2.32.0-r0: task do_check: Started ERROR: Taskhash mismatch b074da4334aff8aa06572e7a8725c941fa6b08de4ce714a65a90c0c0b680abea versus 17375278daed609a7129769b74a1336a37bdef14b534ae85189ccc033a9f2db4 for /home/pokybuild/yocto-worker/qemux86-64/build/meta/recipes-devtools/binutils/binutils-cross-testsuite_2.32.bb:do_check NOTE: recipe binutils-cross-testsuite-2.32.0-r0: task do_check: Succeeded Is caused by a rehash in a dependency happening somewhere earlier in the build and the taint being reset. Change the code so that nostamp taints are preserved to avoid the issue. (Bitbake rev: 61624a3fc38e8546e01356d5ce7a09f21e7094ab) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2019-12-04T12:12:45+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2019-12-04T11:27:07+00:00 urn:sha1:36e40ed24ff7cc0fdb7fd5230256edae7a3c7ade Based on the hashserv's new ability to accept hash mappings, update runqueue to use this through a helper function in siggen. This addresses problems with meta-extsdk-toolchain and its dependency on gdb-cross which caused errors when building eSDK. See the previous commit for more details. (Bitbake rev: 39098b4ba2133f4d9229a0aa4fcf4c3e1291286a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2019-11-25T17:58:11+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2019-11-25T17:18:32+00:00 urn:sha1:cdca61ab03b1cc79f17b9618a03b12e53171783d If a hash is reported to the hash server, the stamp written out by the current task didn't account for any new hash the server may have provided. Fix this so the correct stamp is written. This means "bitbake X; bitbake X" no longer rebuilds lots of things when hashequiv is active. (Bitbake rev: 9dc5178f56ab8ae37e1a646c09117c503e48d072) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2019-09-30T16:23:35+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2019-09-26T13:39:45+00:00 urn:sha1:a73cbe649af5e988eddb4a35b81011cb482d7480 The full paths make the cache useless in the sdk. They also bloat the cache size. They're for human debugging benefit only so compromise and reduce this to the filename. (Bitbake rev: 3b275c4083eae1d3781f0862919af9de83932b0f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2019-09-30T16:23:35+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2019-09-26T13:11:30+00:00 urn:sha1:ba0ff38cabc7091bc8c6287faabede7331c4ab08 Use the unihash in the output filename of sigdata files else the contents of stamp directories is misleading. Write the unihash into the singature to make it clear what happened. (Bitbake rev: feb01ee54d3706fe93768f332054c7532f7209e4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2019-09-30T16:23:35+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2019-09-25T21:47:06+00:00 urn:sha1:7ab4808e0aa4b5ebeb16031afcba55b590518fc5 We need to set the setscene tasklist before we call into the taskhash/unihash code else the behaviour is inconsistent. Avoid reporting hashes for non setscene tasks since we'd never query that. (Bitbake rev: 419a7840b8627278db694029c25df00214d01d96) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2019-09-30T16:23:35+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2019-09-20T11:54:04+00:00 urn:sha1:155249b1db2a038c811b957d58b1d1ac9e798bdb The setscenetasks list needs to be available in the worker contexts else the signature behaviour there mismatches what the server does. Add the data to get/set_taskdata to ensure this happens. (Bitbake rev: 632980ef90fe126b7ba3d138f4d574ae05914779) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>