Hi,

On 16/05/2019 15:56, Cheng-Chang Chang wrote:

Hi Linaro, I am really intrested in LISA... and may I ask some question about it? on github https://github.com/ARM-software/lisa and PDF https://developer.arm.com/-/media/developer/developers/open-source/energy-aw... P.43

I just read and download the source code and try to test my android phone... however, I could not understand "Slack"'s definition in code.

=== Thus two types of test failures can result from these tests:

1. test_task_placement asserts that the placement was energy efficient. In

a big.LITTLE system, if a low-utilisation task was placed on a big CPU then this test should be expected to fail. *2. test_slack asserts that the required bandwidth was provided. In a big.LITTLE system if a high-utilization task was placed on a LITTLE CPU then this test should be expected to fail.* === I run generic.py and can see sometimes "Slack" is negative and sometimes is positive... Negative > test failed, positive > test pass... === How to define this SLACK + or -...? I cannot understand... ====

Slack is a metric reported by rt-app [1].

With rt-app we describe tasks that have a certain period (usually 16ms) and run for a certain duration (e.g. 8ms for a 50% task).

However, this description is done against a calibration that is taken on the highest performance point available - on a big CPU, at the maximum frequency.

So while you expect the task to run for 8ms on a big CPU at maximum frequency, it will take longer to run at lower frequencies (or if it's being coscheduled).

The rt-app doc mentions that in a slightly different wording [2].

So in short the slack is (for simple periodic tasks):

period of the task - time taken to execute a single period's work (e.g. the work equivalent of 8ms of execution for a 50% task)

Positive slack means the work was completed within the period Negative slack means the work took longer than the period, which means we overran into the next phase(s).

The rt-app doc also mentions this [3].

It's a nice metric because this lets us mimic things like frame rendering (16ms period for 60fps), and negative slack is similar to having a jank frame (we couldn't output a frame in 16ms).

Besides, Could I judge my algorithm is worse or better about power efficient by hikey_energy.py & est_power = self.get_power_df(experiment) est_energy = area_under_curve(est_power.sum(axis=1), method='rect (I don't have energy meter.... so.. I can just est by EM. Ofcause, I will design a power for xxx_energy.py)

Really appreciate for your help. I want to write a report and see this module is so excited.

Happy to see that kind of enthusiasm :)

One thing to note however: we've worked on a fairly extensive LISA rework for the past ~6 months. It has lived in the "next" branch, but we've now changed the "master" branch to be that rework.

I mention this because you say you've run generic.py, which has been renamed in that rework (and modified in many, arguably better, ways).

Updating to the new version *will* break your flow, but if you have the time for it you'll get a tool that's much easier to use - it has a documentation now!

https://lisa-linux-integrated-system-analysis.readthedocs.io/en/master/?badg...

[1]: https://github.com/scheduler-tools/rt-app [2]: https://github.com/scheduler-tools/rt-app/blob/master/doc/tutorial.txt#L280 [3]: https://github.com/scheduler-tools/rt-app/blob/master/doc/tutorial.txt#L585

Cheers, Valentin

Best, CCC _______________________________________________ eas-dev mailing list eas-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/eas-dev