On Sat, 2016-02-20 at 18:51 +0000, Barros Pena, Belen wrote: > So I ran a build following the steps above, and had a look at the > data. > Information now shows, which is definitely an improvement :) > > * Time and Disk I/O show for all executed tasks, which is what's > supposed > to happen. > * CPU usage is missing from some executed tasks. This used to happen > before as well, but we never actually worked out why. > > Regarding the numbers, I am not sure how useful is the Disk I/O > figure > expressed in bytes. Should we convert it to something else? And then, > our > big problem is definitely the CPU usage, which shows pretty crazy > numbers. > The highest one in my build was for linux-yocto > do_compile_kernelmodules > at a whopping 2455.15% > > So, Richard Purdie pointed out to us that % over 100 are related to > task > parallelism. And in fact, if I divide the CPU usage value of the > compile > tasks by the value of PARALLEL_MAKE (36), I do get percentages below > 100 > for all of them. In the example of linux-yocto > do_compile_kernelmodules, > we get 68.20% > > If I divide the CPU usage value of all the install tasks by the value > of > PARALLEL_MAKEINST (36), the same happens: % below 100. > > However, we do get % over 100 for tasks that we have been told have > no > parallelism at all. I see such values for unpack, patch, configure, > package and populate_sysroot tasks.
FWIW, do_package does contain parallelism. For unpack/patch/configure/populate_sysroot, there is some parallelism too, in that the parent logging runs in parallel with the child execution. Where these tasks run quickly, I think this could account for the 'parallelism' we see there. Was it only for short running tasks? > So, the question is, why are those > happening? Because for tasks that we know have parallelism we might > be able to divide the value by the parallelism set, as I did for > compile and install tasks. But for the others, I genuinely have no > answer, other that there must be some kind of bug in the data > collection. FWIW I'm very strongly against doing any kind of division by PARALLEL_MAKE or similar numbers as it makes the end resulting number much less meaningful. The idea behind showing these numbers in the UI is to allow people to make decisions based on the numbers. If you do that division, I can't think of useful decisions/actions I could then make on it. For example, "2455%" above tells me that we have a parallelism factor of about 24 in the kernel build. From that I can conclude that whilst the kernel is good, its not making full use of the hardware which would have been a factor of 36 (although the system was likely also busy doing other things unless the task was run in isolation). The only proposal I have is to simply display these as parallelism factors rather than percentage usages. I don't think the data collected is wrong, it does require a certain about of thinking to interpret it though. We're pulling this data direct from the kernel so its unlikely we can get any "better" (easier to interpret?) data either. Cheers, Richard -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
