From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 9A9CCE00B99; Mon, 22 Feb 2016 03:13:20 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from dan.rpsys.net (5751f4a1.skybroadband.com [87.81.244.161]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 8BE06E00AF4 for ; Mon, 22 Feb 2016 03:13:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by dan.rpsys.net (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u1MBCpGd014833; Mon, 22 Feb 2016 11:12:51 GMT Received: from dan.rpsys.net ([127.0.0.1]) by localhost (dan.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qzSgUbbr_MaI; Mon, 22 Feb 2016 11:12:51 +0000 (GMT) Received: from hex ([192.168.3.34]) (authenticated bits=0) by dan.rpsys.net (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u1MBCm5V014829 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 22 Feb 2016 11:12:50 GMT Message-ID: <1456139568.28376.187.camel@linuxfoundation.org> From: Richard Purdie To: "Barros Pena, Belen" , "Smith, Elliot" , "toaster@yoctoproject.org" Date: Mon, 22 Feb 2016 11:12:48 +0000 In-Reply-To: References: <1455893353-15024-1-git-send-email-elliot.smith@intel.com> <1456052640.28376.172.camel@linuxfoundation.org> X-Mailer: Evolution 3.16.5-1ubuntu3.1 Mime-Version: 1.0 Subject: Re: [PATCH 0/5] Fix task buildstats gathering X-BeenThere: toaster@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Web based interface for BitBake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 11:13:20 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Mon, 2016-02-22 at 10:25 +0000, Barros Pena, Belen wrote: > I am not sure what you'd consider a 'short running' task, so here are > a few examples: > > Recipe task time (secs) > CPU usage > db do_unpack 1.29 > 144.34% > linux-libc-headers do_unpack 9.81 > 134.64% > > linux-yocto do_patch 16.40 > 141.12% > > rpm-native do_patch 4.84 > 117.13% > gcc-cross-i586 do_configure 3.25 > 125.24% > > gcc-cross-initial-i586 do_configure 3.27 > 120.50% > > glibc-locale do_populate_sysroot 2.80 > 192.74% > > flex do_populate_sysroot 1.98 > 157.74% I was thinking roughly "under 3 seconds", so some of these are higher that I'd have expected. Could you share the parent utime/stime and cumulative utime/stime for these please, just so we can get a better idea of what was going on there. > And what if we look at the other side of the data? What does a value > of 7.32% mean, like the one we get for netbase do_compile? > > So, in the example of linux-yocto do_compile_kernelmodules, would we > show > '24'? And for netbase do_compile? '0.07'? Yes. 0.07 means it didn't really do much in parallel at all and wasn't using much of a single processor. > Would it be just easier to show resource usage times, since they are > somehow a standard measure that users might be more likely to > recognise? > So we could show either: > > * Child rusage ru_utime + Child rusage ru_stime > * or we split CPU usage into 2 columns, one for ru_utime and the > other for > ru_stime Personally, I see a lot of value in showing these numbers separately. As my question above kind of indicates, you really need several of the numbers to understand exactly what may have been going on within the task and there isn't one number you can show which tells you everything. This is a bit of an aside, but another "missing" piece of information is "what was going on in the system at the same time as this task?". This is the kind of information that the bootchart graph shows really well. If we could click on something and see which other tasks were running at the time this task was, that would be information we can't currently easily obtain. That data is there, we know the start and end times of each of the tasks, so something can compute which ones were running at time X, but its not something that anything is currently doing as we don't have an easy way to display that on the commandline. Cheers, Richard