| Summary: | [krogoth] build-perf:time for build "rootfs" is increased on 2.1.3 compared to 2.1.2 | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Jose Perez C <jose.perez.carranza> |
| Component: | bitbake | Assignee: | Jose Perez C <jose.perez.carranza> |
| Status: | RESOLVED NOTABUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | poky.bs.watcher, poky.watcher |
| Version: | unspecified | ||
| Target Milestone: | 2.1.4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Jose Perez C
2017-06-13 15:26:08 UTC
Jose, these are the times obtained during the weekend on the ubuntu perf machine (ypperf02) #2.1.2 (HEADdetachedatcca8dd1):cca8dd15c8096626052f6d8d25ff1e9a606104a3,2:10.62 (HEADdetachedatcca8dd1):cca8dd15c8096626052f6d8d25ff1e9a606104a3,2:10.68 (HEADdetachedatcca8dd1):cca8dd15c8096626052f6d8d25ff1e9a606104a3,2:10.26 # commit in the middle between 2.1.2 and 2.1.3 (HEADdetachedat4cd7b56):4cd7b5622879e5899dc6c8e0e343eb07a66cf60f,2:11.19 (HEADdetachedat4cd7b56):4cd7b5622879e5899dc6c8e0e343eb07a66cf60f,2:11.29 (HEADdetachedat4cd7b56):4cd7b5622879e5899dc6c8e0e343eb07a66cf60f,2:11.53 # 2.1.3 (HEADdetachedat3565a96):3565a9697f53ba975a1b7235b802f659418746c3,2:12.06 (HEADdetachedat3565a96):3565a9697f53ba975a1b7235b802f659418746c3,2:11.73 (HEADdetachedat3565a96):3565a9697f53ba975a1b7235b802f659418746c3,2:11.82 meaning that between *.2 and *.3 there is an increase of around one second which is pretty small compared to what you observed. I will let you decide what to do with this bug. One more thing: after 2.1.3, is the perf machine rebooted? Experimentally, RP has observed that long uptimes may lead longer perf times, so it may be wise to reboot machines once in a time. (In reply to comment #1) > Jose, > > these are the times obtained during the weekend on the ubuntu perf machine > (ypperf02) > > > #2.1.2 > (HEADdetachedatcca8dd1):cca8dd15c8096626052f6d8d25ff1e9a606104a3,2:10.62 > (HEADdetachedatcca8dd1):cca8dd15c8096626052f6d8d25ff1e9a606104a3,2:10.68 > (HEADdetachedatcca8dd1):cca8dd15c8096626052f6d8d25ff1e9a606104a3,2:10.26 > > # commit in the middle between 2.1.2 and 2.1.3 > (HEADdetachedat4cd7b56):4cd7b5622879e5899dc6c8e0e343eb07a66cf60f,2:11.19 > (HEADdetachedat4cd7b56):4cd7b5622879e5899dc6c8e0e343eb07a66cf60f,2:11.29 > (HEADdetachedat4cd7b56):4cd7b5622879e5899dc6c8e0e343eb07a66cf60f,2:11.53 > > # 2.1.3 > (HEADdetachedat3565a96):3565a9697f53ba975a1b7235b802f659418746c3,2:12.06 > (HEADdetachedat3565a96):3565a9697f53ba975a1b7235b802f659418746c3,2:11.73 > (HEADdetachedat3565a96):3565a9697f53ba975a1b7235b802f659418746c3,2:11.82 > > meaning that between *.2 and *.3 there is an increase of around one second > which is pretty small compared to what you observed. I will let you decide > what to do with this bug. I will close this as not a bug > > One more thing: after 2.1.3, is the perf machine rebooted? Experimentally, > RP has observed that long uptimes may lead longer perf times, so it may be > wise to reboot machines once in a time. Yes that was the cause also observed on most recent releases, There is a plan already set to reboot machines on a regularly, now the numbers are more consistent. |