On 11 June 2015 at 13:56, Alex Shi alex.shi@linaro.org wrote:
This script is a part of our LAVA integration and doesn't need to go to upstream LKP. What's missing (if I understand correctly) from LKP are these values:
Operation Count AvgLat MaxLat
NTCreateX 2011265 0.848 1478.406 Close 1477355 0.350 1165.450 Rename 85163 1.263 62.960 Unlink 406180 0.517 1287.522 Deltree 48 57.127 186.366 Mkdir 24 0.009 0.027 Qpathinfo 1823148 0.567 1445.759 Qfileinfo 319390 0.272 486.622 Qfsinfo 334240 0.421 1161.980 Sfileinfo 163808 0.558 993.785 Find 704767 0.874 1164.246 WriteX 1002240 0.032 9.801 ReadX 3152551 0.032 662.566 LockX 6550 0.011 0.727 UnlockX 6550 0.005 0.535 Flush 140954 0.613 53.237
If they are important for you, LKP needs to be patched to include them in the LKP results, not LAVA results. Our LAVA integration takes only what LKP produces.
Yes, they are sub-cases of dbench benchmark. They are meaningful as each of file-system operations. And they are the only meaningful benchmark results among mixed profiles. I mean that profile data are important, but normally no one care them unless the benchmark result changes.
that is clear now. I'll add a task to patch it in LKP.
[cut]
that isn't possible at this stage. LAVA structures the results this way.
The following format would be better than current. | kernel 1| kernel 2| |benchmark 1| value x | value x2| |benchmark 2| value y | value y2|
Again, this isn't possible for single run as we're only running on a single kernel. Such feature requires raw data postprocessing ans most likely will not be a part of LAVA. LAVA will be used to run tests and store raw data. The comparison will happen somewhere else. I just had a meeting with ARM ART (Android RunTime) team and they requested similar comparison features for their benchmarks. They are willing to share code they're using. This includes DB for storing the benchmark results and some scripts that do comparison. So eventually we will get the build-to-build or branch-to-branch comparison. For the moment let's focus on collecting the benchmark data and making sure we store everything you need.
It is possible to get this format from dashboard?
Not that I'm aware of, sorry.
milosz
+1 on that. Let's try to identify the important data, store it and have ready for postprocessing. If LKP is missing something, we need to fix it upstream.
Thanks a lot! It would be very useful for performance tracking, especially for upstream kernel monitor on ARM boards!