[LTP] [PATCH V2 1/2] ltp: Add the ability to specify the latency constraint

[Daniel Lezcano]

On 11/08/2017 17:28, Cyril Hrubis wrote:
> Hi!
>>> This seems to be a bit too specific to me, I would be more happy 
>>> if we named it "measures_sleep_time" or something that describes 
>>> what the testcase does rather than calling it after specific 
>>> workaround.
>> 
>> I'm sorry, I don't get the point. The latency is a system
>> parameter for any kind of run. Here it is in the common tst lib
>> code as the constraint may be needed for any other new test. I
>> don't understand the 'measures_sleep_time', there is no connection
>> with the latency word.
> 
> My point of view is that this is very specific tuning parameter and 
> in ideal world the testcases would not need to touch kernel tuning 
> knobs unless the knob is what is being tested, but we do not live in 
> an ideal world either so some kind of solution is desirable. On the 
> other hand there is plenty of different tuning knobs there and I 
> would like to avoid putting each of them into the test library as 
> another flag to be set in the test structure.
> 
>> Perhaps the cpu_dma_latency needs a better explanation:
>> 
>> When the CPU has no task in its runqueue, the kernel will run a 
>> special task (the idle task). When entering in the idle routine,
>> it will use an idle state process selection based on how long we 
>> predict the CPU will be sleeping (based on a mix of wake up 
>> statistics and timer events) as well as an exit latency
>> constraint. The deeper the idle state is, the longer the latency to
>> wakeup is and the more energy we save.
>> 
>> The number of idle states is hardware specific, as well as the idle
>> state characteristics. For example, for an x86,i7 the deepest idle
>> state's exit latency is 86us, on other platforms (eg. mobile), the
>> deepest idle state's exit latency could more than 1500us (or 
>> less).
>> 
>> Under certain circumstances, you don't want your CPU to go to a
>> too deep idle state because you need fast response: eg. playing a
>> game, reading a mp3 or a HD video (otherwise you miss frames). The 
>> application will then set a cpu_dma_latency constraint and as the 
>> kernel checks this latency when selecting an idle state, deep idle 
>> state will be skipped.
>> 
>> For the specific pselect test, we measure the drift between the 
>> expected wakeup and the observed one. With the energy framework,
>> we added an unacceptable (for the test) delay. This test does not 
>> check the latency, it checks if the wakeup period from the 
>> *pselect* syscall is acceptable, in absolute, so we need to put 
>> apart the idle routine during this specific test.
>> 
>> Technically speaking, the cpu_dma_latency is set by opening the 
>> file /dev/cpu_dma_latency and writing the value but as soon as you 
>> close the file descriptor, the constraint is removed from the 
>> kernel. So in this case, any test setting the cpu_dma_latency will 
>> have the file descriptor close at exit time, the constraint is 
>> bound to the test itself.
> 
> So if I'm getting this correctly the kernel tries to save power 
> agressively in your case since it knows when next timer expires and 
> that waking up from deep idle state would make the timer slack, 
> right? From that point of view this more or less looks like an 
> workaround :-).

No, it is not trying to save power aggressively. It has exactly the same
behavior than other platforms/arch. The kernel does not have a
constraint in terms of latency, so it does not discriminate any idle
state. Luckily the test works on different architecture because:

 1. the architecture / platform does not have deep idle state
    or
 2. the deep idle state have fast exit latency

However, there are some discussions around setting in the kernel
a timer to force a wakeup a bit sooner (basically minus the exit
latency) in order to reduce the drift but that won't be for tomorrow
because other parameters are entering in the equation (eg. latency can
change depending on the CPU clock).

> But what I do not understand here is why pselect requires special 
> handling while rest of the timer testcases that do exactly the same 
> and end up using the very same hrtimer framework in kernel work 
> fine.
> We do have at least select() and poll() 

I tested them individually and they fail with the userspace governor+min
freq.

If I change the cpufreq governor to ondemand and run select0[0-4] one
after other, they don't fail. The reason is because the previous tests
have a CPU duty cycle long enough and the governor decides to stay at a
high frequency, thus reducing the exit latency.

> tests that should end up 
> using the same timer with the same slack formula in kernel and hence 
> should fail in the very same way. And possibly rest of the timer 
> testcases should likely fail as well since these are not that 
> different either.

The latencies introduced by the kernel energy saving framework can make
these tests to fail and it is impossible to get rid of that, except by
setting the latency to zero when running specific test cases.


> Are you, by any chance, using latest stable release? Since we had 
> rewritten all the timer precision tests recently in:
> 
> https://github.com/linux-test-project/ltp/commit/c459654db64cd29177a382ab178fdd5ad59664e4

Yes, I am.


>>> Also shouldn't this be set automatically for all timer related 
>>> testcases (these that make use of the sampling function) rather 
>>> than just for the pselect one? If so we should set the flag in 
>>> the tst_timer_test.c library instead. Or we can also stick the 
>>> latency setup/cleanup into the tst_timer_test.c as well and
>>> don't bother with adding more flags into the tst_test structure
>>> (see timer_setup() and timer_cleanup() in the tst_timer_test.c).
>> 
>> I'm not sure. We may want to measure everything together (timer + 
>> drift + energy framework latencies) in other testcases. I think it 
>> is fine if we let the test program to decide what latency he wants 
>> to set.
> 
> Are you using latest git with the timer library? I would suspect that
> all of the test would need the very same treatement  since the test
> paramters and maximal error margins are all defined in a single place
> now.

Do you mean setting the zero latency in the tst_timer_test ?


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog