The Power of System Call Traces: Predicting the Software Energy Consumption Impact of Changes

This blog post is from the work - “The Power of System Call Traces: Predicting the Software Energy Consumption Impact of Changes” that has been accepted at CASCON 2014 to be held at Toronto from 3-5 November 2014 . The work relates the energy consumption of android applications to system calls made by the application. You can find the work here.

Limited battery life is a pressing issue for the common smart phone users. This has forced the developers to consider the energy profile of their application. However, profiling energy consumption of an application requires special external instrumentation for measuring the current and voltage reading to estimate the power consumption. Studies have shown that on device measurements are not reliable. Thus, developers for the most part are clueless about the impact of software change on their application's energy profile.

System calls, act as buffer between the OS and the applications to provide the OS services and resources to the applications. It is hence, interesting to consider the relationship between the energy profile and system call trace of the application. So, we considered two applications – Firefox and Calculator on Android. We took 101 and 156 versions of the Calculator¹ and Firefox² applications respectively, with each version being separated by one commit in their repositories.

To get the system call trace, we use the strace tool , that needs to be cross compiled for Android³. The strace executable cross-compiled needs to be placed either on the phone or even on a system that's connected to phone. To trace an application just use “strace -c appProcessID”, after starting the application⁴. If it is on the system, connected to phone, the command can be run from the adb shell. For the Calculator application, we had 26 different system calls made, while for the Firefox we had 53 different system call invocation.

You will also like to device a particular test sequence, for the applications, which can then be emulated on the phone using the monkey script runner. To devise the tests, you will need to emulate the test sequence on the android emulator, which ships with the Andorid studio. Just enable the developer options tool on the device, which helps to note the pixel values of the screen. To emulate a touch action on the phone, we note the pixel value at the screen where touch is made. Similarly, for a swipe action , we note the starting and ending pixels on the screen. The emulator provides the option to note the pixel values at each tap or swipe on the emulator screen. Using this noted sequence, we need to build the monkey script, that can be run on the phone using the monkey runner, that also ships with the android -sdk, and needs android-ndk.

We had a special test bed to measure the energy use, called Green Miner. We tried to establish the relationship between system call counts and energy usage of the applications. We did multiple tests for each version to see whether, a change in the system call trace leads to a significant change in the energy use. To achieve this, we use the Student's t-tests to establish whether the two consecutive versions are same with respect to system call profile and energy consumption. Now, developers are not statisticians, so we tried to formulate a rule of thumb to help them say whether they should be concerned when their system call count change.

To do so, we calculate simple frequency of occurrence of this phenomenon, “Significant Change in system call count leads to significant change in energy consumption”. To see the significant change in the applications, system call count, strace the previous version and as well strace the next version after the change in the application code, multiple times, say 10 times. Then to see whether the change in the system call count is significant, use the t-tests. Example below shows the same in R, where the 3-D matrix sysCounts, contains the system call counts for the ten runs for a version:

ttestResult <- array(0,dim=c( 100,26 ))

noSysCalls <- array(0,dim=c(26, 10 , 101))

/* Read the data to noSysCalls matrix */

for (y in 1:noSysCalls)

{

          for (i in 1:(noVersions-1))

         {

             tvalue = t.test(sysCounts[y,,i],sysCounts[y,,i+1])

             ttestResult[i,y]=tvalue$p.value

         }

}

ttestResult saves the result of the Student's t-test. To test the significance of change between versions we need to see p-value < 0.05.

For the Calculator application results were astounding, some system calls like pread, or stat64 had 100% frequency of occurrence of this phenomenon while on an average for each system call, this phenomenon occurred 58% of the times. For the Firefox, application, with the sheer number of system calls as compared to the Calculator application, this average frequency rate is 25%. Hence, with once in four times, a system call's count changes significantly from the previous one, we can say that there is a change in the energy profile of the application.

This saves the developers from the worry of setting up an exclusive and expensive instrumentation to measure the power use, to see the impact of software change on the energy. They just need to use the strace to profile the system calls. Hence, developers just need to notice the change in the system calls profile, and hence can expect the change in energy use of their applications.

¹ https://github.com/Xlythe/android_packages_apps_Calculator/

² http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

³ http://muzso.hu/2012/04/21/how-to-compile-strace-for-use-on-an-android-phone-running-an-arm-cpu

⁴ http://mohsin-junaid.blogspot.ca/2012/12/how-to-strace-your-android-application.html