ltp: Add the ability to specify the latency constraint

The pselect_01 testcase works well on an x86 as it is a fast platform, with fast exit latency idle routine.

However on ARM[64] the idle routine can take much more time, for example 1500us.

The pselect fails on the ARM[64] platforms because of these slow exit latencies, the delay between the expected expiration and the observed one is not acceptable.

The fix could be to increase the deviation on ARM64 but that wouldn't make sense as some platforms, for the same architecture, can have faster or different delays, hence we can potentially miss a bug.

The simplest solution is to set the cpu_dma latency constraint to zero, so the idle driver will always choose the fastest idle state, thus fixing the issue above. The latency constraint will apply only for this test.

Signed-off-by Daniel Lezcano <[email protected]>

---
 testcases/kernel/syscalls/pselect/pselect01.c | 3 +++
 1 file changed, 3 insertions(+)

testcases/kernel/syscalls/pselect/pselect01.c +3 -0

index a2b5339..42027b6 100644
@@ -44,6 +44,9 @@ int sample_fn(int clk_id, long long usec)
 }
 
 static struct tst_test test = {
+	.needs_root = 1,
+	.needs_latency = 1,
+	.latency = 0,
 	.tid = "pselect()",
 	.sample = sample_fn,
 };

Quoted 14 lines · Daniel Lezcano

The pselect_01 testcase works well on an x86 as it is a fast platform, with fast exit latency idle routine.

However on ARM[64] the idle routine can take much more time, for example 1500us.

The pselect fails on the ARM[64] platforms because of these slow exit latencies, the delay between the expected expiration and the observed one is not acceptable.

The fix could be to increase the deviation on ARM64 but that wouldn't make sense as some platforms, for the same architecture, can have faster or different delays, hence we can potentially miss a bug.

Quoted 3 lines

The simplest solution is to set the cpu_dma latency constraint to zero, so the idle driver will always choose the fastest idle state, thus fixing the issue above. The latency constraint will apply only for this test.

I think a more generic LTP-wide solution could be made; there are more tests that fail ie. on virtualized environments because of CPU over- provisioning on the host (x86, s390, ppc, etc.)

and I can imagine ie.
networking tests having similar needs as well (probably currently worked around using big timeouts).

Basically some system that would allow a user to set some "latency multiplier" based on the system under test, so that ie. dedicated x86 machines with fairly deterministic CPU/net/etc. scheduling could have it set low, and so that other systems could still run tests that are now deemed unsuitable for such hardware.

Quoted 20 lines

Signed-off-by Daniel Lezcano <[email protected]>

---
 testcases/kernel/syscalls/pselect/pselect01.c | 3 +++
 1 file changed, 3 insertions(+)

testcases/kernel/syscalls/pselect/pselect01.c +3 -0

index a2b5339..42027b6 100644
@@ -44,6 +44,9 @@ int sample_fn(int clk_id, long long usec)
 }
 
 static struct tst_test test = {
+	.needs_root = 1,
+	.needs_latency = 1,
+	.latency = 0,
 	.tid = "pselect()",
 	.sample = sample_fn,
 };

Quoted 23 lines · Daniel Lezcano

Quoted 21 lines

The pselect_01 testcase works well on an x86 as it is a fast platform, with
fast exit latency idle routine.

However on ARM[64] the idle routine can take much more time, for example 1500us.

The pselect fails on the ARM[64] platforms because of these slow exit latencies,
the delay between the expected expiration and the observed one is not acceptable.

The fix could be to increase the deviation on ARM64 but that wouldn't make sense as some platforms, for the same architecture, can have faster or different delays, hence we can potentially miss a bug.

The simplest solution is to set the cpu_dma latency constraint to zero, so the
idle driver will always choose the fastest idle state, thus fixing the issue
above. The latency constraint will apply only for this test.

Quoted 3 lines

I think a more generic LTP-wide solution could be made; there are more tests that fail ie. on virtualized environments because of CPU over- provisioning on the host (x86, s390, ppc, etc.)

Not sure a latency constraint will fix the above.

The ltp test suites provides a set of tests. Some of them are checking the test
happens in a specified amount of time.

Unfortunately, some platforms have slow power management routines adding more than 1.5ms to wakeup from a deep idle state. This duration is far too long to be acceptable when we are trying the measure a speficied routine with a timeout
reasonably delayed. For example, the testcases/kernel/syscalls/pselect_01 is failing for this reason.

This patch gives the opportunity to the testcase to specify the latency constraint when running. This option must be used with the needs_root in order
to have the right privileges.

Signed-off-by Daniel Lezcano <[email protected]>

---
 include/tst_test.h |  4 ++++
 lib/tst_test.c     | 18 ++++++++++++++++++
 2 files changed, 22 insertions(+)

include/tst_test.h +4 -0

index e90312a..519fd4c 100644
@@ -124,6 +124,7 @@ struct tst_test {
 	int needs_checkpoints:1;
 	int format_device:1;
 	int mount_device:1;
+	int needs_latency:1;
 
 	/* Minimal device size in megabytes */
 	unsigned int dev_min_size;

@@ -154,6 +155,9 @@ struct tst_test {
 
 	/* NULL terminated array of resource file names */
 	const char *const *resource_files;
+
+	/* Latency constraint to be set for the test */
+	int latency;
 };
 
 /*

lib/tst_test.c +0 -0

index 4c30eda..485515e 100644

Signed-off-by Daniel Lezcano <[email protected]>

---
 include/tst_test.h |  4 ++++
 lib/tst_test.c     | 28 ++++++++++++++++++++++++++++
 2 files changed, 32 insertions(+)

include/tst_test.h +1 -0

index e90312a..519fd4c 100644
@@ -124,6 +124,7 @@ struct tst_test {
 	int needs_checkpoints:1;
 	int format_device:1;
 	int mount_device:1;
+	int needs_latency:1;
 
 	/* Minimal device size in megabytes */
 	unsigned int dev_min_size;

include/tst_test.h +0 -0

 /*

lib/tst_test.c +28 -0

index 4c30eda..717a782 100644
@@ -619,6 +619,31 @@ static void copy_resources(void)
 		TST_RESOURCE_COPY(NULL, tst_test->resource_files[i], NULL);
 }
 
+static int set_latency(void)
+{
+	int fd, ret;
+
+	fd = open("/dev/cpu_dma_latency", O_WRONLY);
+	if (fd < 0) {
+		/*
+		 * In case we are running on old kernel where the cpu_dma latency does
+		 * not exist, do not fail, just inform and bail out.
+		 */
+		if (errno == ENOENT) {
+			tst_res(TINFO, "/dev/cpu_dma_latency does not exists\n");
+			return 0;
+		}
+
+		return fd;
+	}
+
+	ret = write(fd, &tst_test->latency, sizeof(tst_test->latency));
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
+
 static const char *get_tid(char *argv[])
 {
 	char *p;

@@ -736,6 +761,9 @@ static void do_setup(int argc, char *argv[])
 
 	if (tst_test->resource_files)
 		copy_resources();
+
+	if (tst_test->needs_latency && set_latency())
+		tst_brk(TBROK, "Failed to set cpu latency");
 }
 
 static void do_test_setup(void)

Signature · 5 lines

2.1.4


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Hi!

Quoted 20 lines

Signed-off-by Daniel Lezcano <[email protected]>

---
 include/tst_test.h |  4 ++++
 lib/tst_test.c     | 28 ++++++++++++++++++++++++++++
 2 files changed, 32 insertions(+)

include/tst_test.h +1 -0

index e90312a..519fd4c 100644
@@ -124,6 +124,7 @@ struct tst_test {
 	int needs_checkpoints:1;
 	int format_device:1;
 	int mount_device:1;
+	int needs_latency:1;
 
 	/* Minimal device size in megabytes */
 	unsigned int dev_min_size;

@@ -154,6 +155,9 @@ struct tst_test {
 

include/tst_test.h struct tst_test { · line 161

Quoted 6 lines

include/tst_test.h +3 -0

 	/* NULL terminated array of resource file names */
 	const char *const *resource_files;
+
+	/* Latency constraint to be set for the test */
+	int latency;
 };

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.

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).

Quoted 3 lines

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.

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.

Quoted 7 lines

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.

Hi!

Quoted 10 lines

Quoted 4 lines

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.

Quoted 30 lines

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.

Quoted 6 lines

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 :-).

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()

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.

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

Quoted 8 lines

Quoted 7 lines

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).

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 6 lines

Quoted 4 lines

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.

That explains it. Previously each of the timer testcases had it's own PASS/FAIL criteria and each of them was slightly different. We got rid of that mess recetly and so the latest git has a timer measurement library and the test only defines a sampling function now. We also did quite a lot of testing to make sure that the test are stable now. And because of that we take more samples and apply discarded mean to get rid of random outliners. But we did most of the testing on x86 hardware so it's possible that it still needs some adjustements.

Can you, please, try with the latest git to see if these tests works for you now? And then, in a case that they stil fail, we will figure out how to fix them. Most likely we will patch the timer test library, either to loosen the crieria or to keep the cpu_dma_latecy open while we sample the timers.

Quoted 8 lines

That explains it. Previously each of the timer testcases had it's own PASS/FAIL criteria and each of them was slightly different. We got rid of that mess recetly and so the latest git has a timer measurement library and the test only defines a sampling function now. We also did quite a lot of testing to make sure that the test are stable now. And because of that we take more samples and apply discarded mean to get rid of random outliners. But we did most of the testing on x86 hardware so it's possible that it still needs some adjustements.

IMO, you should not try to adjust this because there can be a so big gap between some arch/platforms in term of exit_latency that can make the test to miss a bug. I mean being more tolerant for one arch can make the test miss a bug on another arch.

eg.

exynos4 : 5000us
at91: 10us
ux500: 70us
mediatek: 600us
ppc: 10us
x86: 86us
sh mobile: 2300us

etc...

The simplest and cleanest way is to reduce the latency to its minimum in order to reduce the energy framework impact on the tests.

It is recent the mobile runs ltp.

Quoted 5 lines

Can you, please, try with the latest git to see if these tests works for you now? And then, in a case that they stil fail, we will figure out how to fix them. Most likely we will patch the timer test library, either to loosen the crieria or to keep the cpu_dma_latecy open while we sample the timers.

There is a misunderstanding. I ran the tests (and they fail) on the latest one 4a707d417e3f95025fe6c707e2763e84b2bed29a.

Hi!

Quoted 24 lines

Quoted 8 lines

That explains it. Previously each of the timer testcases had it's own PASS/FAIL criteria and each of them was slightly different. We got rid of that mess recetly and so the latest git has a timer measurement library and the test only defines a sampling function now. We also did quite a lot of testing to make sure that the test are stable now. And because of that we take more samples and apply discarded mean to get rid of random outliners. But we did most of the testing on x86 hardware so it's possible that it still needs some adjustements.

IMO, you should not try to adjust this because there can be a so big gap between some arch/platforms in term of exit_latency that can make the test to miss a bug. I mean being more tolerant for one arch can make the test miss a bug on another arch.

eg.

exynos4 : 5000us
at91: 10us
ux500: 70us
mediatek: 600us
ppc: 10us
x86: 86us
sh mobile: 2300us

Quoted 1 line

etc...

Ok.

Quoted 4 lines

The simplest and cleanest way is to reduce the latency to its minimum in order to reduce the energy framework impact on the tests.

It is recent the mobile runs ltp.

Sounds reasonably then.

Quoted 6 lines

Quoted 5 lines

Can you, please, try with the latest git to see if these tests works for you now? And then, in a case that they stil fail, we will figure out how to fix them. Most likely we will patch the timer test library, either to loosen the crieria or to keep the cpu_dma_latecy open while we sample the timers.

Quoted 2 lines

There is a misunderstanding. I ran the tests (and they fail) on the latest one 4a707d417e3f95025fe6c707e2763e84b2bed29a.

Okay, and do all of the timer tests fail or just some subset?

And even if only subset of them fails I would still consider changing the timer library rather than individual testcases.

Quoted 2 lines

And even if only subset of them fails I would still consider changing the timer library rather than individual testcases.

Yes, that make sense.

Do you want keep the latency option for future use?

Hi!

Quoted 3 lines

Quoted 2 lines

And even if only subset of them fails I would still consider changing the timer library rather than individual testcases.

Quoted 3 lines

Yes, that make sense.

Do you want keep the latency option for future use?

I tend not to add anything just in case that we may need it later in order to keep the test library as small as possible, it's complex enough even as it is. Moreover we can always add it easily when we find a test that requires it.

Quoted 8 lines

Quoted 3 lines

Yes, that make sense.

Do you want keep the latency option for future use?

I tend not to add anything just in case that we may need it later in order to keep the test library as small as possible, it's complex enough even as it is. Moreover we can always add it easily when we find a test that requires it.

Setting the latency to zero in tst_timer_start(), if the opening of the /dev/cpu_dma_latency file fails, we continue but issue a warning with

	tst_resm(TWARN,
		"Failed to open '/dev/cpu_dma_latency': %s',
		strerror(errno));

is ok ?

Hi!

Quoted 12 lines

Quoted 8 lines

Quoted 3 lines

Yes, that make sense.

Do you want keep the latency option for future use?

I tend not to add anything just in case that we may need it later in order to keep the test library as small as possible, it's complex enough even as it is. Moreover we can always add it easily when we find a test that requires it.

Setting the latency to zero in tst_timer_start(), if the opening of the /dev/cpu_dma_latency file fails, we continue but issue a warning with

Quoted 5 lines

	tst_resm(TWARN,
		"Failed to open '/dev/cpu_dma_latency': %s',
		strerror(errno));

is ok ?

Issuing TWARN marks the test as a failure, you should go for TINFO if you want just inform the user about non-fatal problem.

Also are you sure that tst_timer_start() is the right place to open the file? That function is called ~1000 times in each timer test hence this would add quite a bit of overhead. Why don't we just put it into the timer_setup() in the lib/tst_timer_test.c that is called once at the start of the test?

Hi,

I'm running into similar problem on "Dell Precision 5820 tower", with Intel(R) Xeon(R) W-2133 CPU @ 3.60GHz, but I can't find any /proc /sys knob that would help.

# uname -r
4.14.5

# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance

Any timer related tests are reliably failing on longer timeouts:
---
tst_test.c:934: INFO: Timeout per run is 0h 05m 00s
tst_timer_test.c:356: INFO: CLOCK_MONOTONIC resolution 1ns
tst_timer_test.c:368: INFO: prctl(PR_GET_TIMERSLACK) = 50us
tst_timer_test.c:275: INFO: poll() sleeping for 1000us 500 iterations, threshold 450.01us tst_timer_test.c:318: INFO: min 1095us, max 1098us, median 1096us, trunc mean 1095.99us (discarded 25) tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 2000us 500 iterations, threshold 450.01us

tst_timer_test.c:318: INFO: min 2062us, max 2138us, median 2137us, trunc mean 2135.98us (discarded 25) tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 5000us 300 iterations, threshold 450.04us tst_timer_test.c:318: INFO: min 5262us, max 5263us, median 5262us, trunc mean 5262.20us (discarded 15) tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 10000us 100 iterations, threshold 450.33us tst_timer_test.c:318: INFO: min 10318us, max 10471us, median 10471us, trunc mean 10469.07us (discarded 5) tst_timer_test.c:321: FAIL: poll() slept for too long

SCHED_OTHER or SCHED_FIFO -> FAIL intel_idle.max_cstate=0 processor.max_cstate=1 -> FAIL echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo -> FAIL idle=halt -> FAIL
idle=poll -> FAIL

Only thing I found to help is to keep CPU slightly busy with
taskset -c 1 sh -c "while [ True ]; do usleep 100; done"

After that it started to PASS:

# taskset -c 1 ./poll02
tst_test.c:934: INFO: Timeout per run is 0h 05m 00s
tst_timer_test.c:356: INFO: CLOCK_MONOTONIC resolution 1ns
tst_timer_test.c:368: INFO: prctl(PR_GET_TIMERSLACK) = 50us
tst_timer_test.c:275: INFO: poll() sleeping for 1000us 500 iterations, threshold 450.01us
tst_timer_test.c:318: INFO: min 1004us, max 1325us, median 1072us, trunc mean 1149.29us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 2000us 500 iterations, threshold 450.01us
tst_timer_test.c:318: INFO: min 2007us, max 2326us, median 2075us, trunc mean 2158.64us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 5000us 300 iterations, threshold 450.04us
tst_timer_test.c:318: INFO: min 5006us, max 5345us, median 5074us, trunc mean 5146.84us (discarded 15)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 10000us 100 iterations, threshold 450.33us
tst_timer_test.c:318: INFO: min 10004us, max 10364us, median 10075us, trunc mean 10128.61us (discarded 5)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 25000us 50 iterations, threshold 451.29us
tst_timer_test.c:318: INFO: min 25006us, max 25359us, median 25072us, trunc mean 25137.48us (discarded 2)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 100000us 10 iterations, threshold 537.00us
tst_timer_test.c:318: INFO: min 100010us, max 100372us, median 100125us, trunc mean 100167.78us (discarded 1)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 1000000us 2 iterations, threshold 4400.00us
tst_timer_test.c:318: INFO: min 1000843us, max 1000920us, median 1000843us, trunc mean 1000843.00us (discarded 1)
tst_timer_test.c:333: PASS: Measured times are within thresholds

Summary:

passed   7
failed   0
skipped  0

warnings 0

Any ideas?

Regards,
Jan

Quoted 40 lines

Hi,

I'm running into similar problem on "Dell Precision 5820 tower", with Intel(R) Xeon(R) W-2133 CPU @ 3.60GHz, but I can't find any /proc /sys knob that would help.

# uname -r
4.14.5

# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance

Any timer related tests are reliably failing on longer timeouts:
---
tst_test.c:934: INFO: Timeout per run is 0h 05m 00s tst_timer_test.c:356: INFO: CLOCK_MONOTONIC resolution 1ns tst_timer_test.c:368: INFO: prctl(PR_GET_TIMERSLACK) = 50us tst_timer_test.c:275: INFO: poll() sleeping for 1000us 500 iterations, threshold 450.01us
tst_timer_test.c:318: INFO: min 1095us, max 1098us, median 1096us, trunc mean 1095.99us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 2000us 500 iterations, threshold 450.01us
tst_timer_test.c:318: INFO: min 2062us, max 2138us, median 2137us, trunc mean 2135.98us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 5000us 300 iterations, threshold 450.04us

Quoted 8 lines

tst_timer_test.c:318: INFO: min 5262us, max 5263us, median 5262us, trunc mean 5262.20us (discarded 15)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 10000us 100 iterations, threshold 450.33us
tst_timer_test.c:318: INFO: min 10318us, max 10471us, median 10471us, trunc mean 10469.07us (discarded 5)
tst_timer_test.c:321: FAIL: poll() slept for too long

Are you running the tests with this zero latency patch included ?

Quoted 57 lines

SCHED_OTHER or SCHED_FIFO -> FAIL intel_idle.max_cstate=0 processor.max_cstate=1 -> FAIL echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo -> FAIL idle=halt -> FAIL
idle=poll -> FAIL

Only thing I found to help is to keep CPU slightly busy with
taskset -c 1 sh -c "while [ True ]; do usleep 100; done"

After that it started to PASS:

# taskset -c 1 ./poll02
tst_test.c:934: INFO: Timeout per run is 0h 05m 00s
tst_timer_test.c:356: INFO: CLOCK_MONOTONIC resolution 1ns
tst_timer_test.c:368: INFO: prctl(PR_GET_TIMERSLACK) = 50us
tst_timer_test.c:275: INFO: poll() sleeping for 1000us 500 iterations,
threshold 450.01us
tst_timer_test.c:318: INFO: min 1004us, max 1325us, median 1072us, trunc
mean 1149.29us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 2000us 500 iterations,
threshold 450.01us
tst_timer_test.c:318: INFO: min 2007us, max 2326us, median 2075us, trunc
mean 2158.64us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 5000us 300 iterations,
threshold 450.04us
tst_timer_test.c:318: INFO: min 5006us, max 5345us, median 5074us, trunc
mean 5146.84us (discarded 15)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 10000us 100 iterations,
threshold 450.33us
tst_timer_test.c:318: INFO: min 10004us, max 10364us, median 10075us, trunc
mean 10128.61us (discarded 5)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 25000us 50 iterations,
threshold 451.29us
tst_timer_test.c:318: INFO: min 25006us, max 25359us, median 25072us, trunc
mean 25137.48us (discarded 2)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 100000us 10 iterations,
threshold 537.00us
tst_timer_test.c:318: INFO: min 100010us, max 100372us, median 100125us,
trunc mean 100167.78us (discarded 1)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 1000000us 2 iterations,
threshold 4400.00us
tst_timer_test.c:318: INFO: min 1000843us, max 1000920us, median 1000843us,
trunc mean 1000843.00us (discarded 1)
tst_timer_test.c:333: PASS: Measured times are within thresholds

Summary:

passed   7
failed   0
skipped  0

Quoted 7 lines

warnings 0

Any ideas?

Regards,
Jan

--
<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

--
Mailing list info: https://lists.linux.it/listinfo/ltp

----- Original Message -----

Quoted 50 lines · Jan Stancek

Quoted 40 lines

Hi,

I'm running into similar problem on "Dell Precision 5820 tower", with Intel(R) Xeon(R) W-2133 CPU @ 3.60GHz, but I can't find any /proc /sys knob that would help.

# uname -r
4.14.5

# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance

Any timer related tests are reliably failing on longer timeouts:
---
tst_test.c:934: INFO: Timeout per run is 0h 05m 00s tst_timer_test.c:356: INFO: CLOCK_MONOTONIC resolution 1ns tst_timer_test.c:368: INFO: prctl(PR_GET_TIMERSLACK) = 50us tst_timer_test.c:275: INFO: poll() sleeping for 1000us 500 iterations, threshold 450.01us
tst_timer_test.c:318: INFO: min 1095us, max 1098us, median 1096us, trunc mean 1095.99us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 2000us 500 iterations, threshold 450.01us
tst_timer_test.c:318: INFO: min 2062us, max 2138us, median 2137us, trunc mean 2135.98us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 5000us 300 iterations, threshold 450.04us

Quoted 8 lines

tst_timer_test.c:318: INFO: min 5262us, max 5263us, median 5262us, trunc mean 5262.20us (discarded 15)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 10000us 100 iterations, threshold 450.33us
tst_timer_test.c:318: INFO: min 10318us, max 10471us, median 10471us, trunc mean 10469.07us (discarded 5)
tst_timer_test.c:321: FAIL: poll() slept for too long

Quoted 1 line

Are you running the tests with this zero latency patch included ?

Yes, I'm running ltp release 20170929, which has your patch.

...
[pid 18276] 09:59:21.379883 open("/dev/cpu_dma_latency", O_WRONLY) = 3 [pid 18276] 09:59:21.379906 write(3, "\0\0\0\0", 4) = 4
...

I tried it without that patch, and it started failing more with smaller timeouts.

Regards,
Jan

Quoted 77 lines

Quoted 57 lines

SCHED_OTHER or SCHED_FIFO -> FAIL intel_idle.max_cstate=0 processor.max_cstate=1 -> FAIL echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo -> FAIL idle=halt -> FAIL
idle=poll -> FAIL

Only thing I found to help is to keep CPU slightly busy with
taskset -c 1 sh -c "while [ True ]; do usleep 100; done"

After that it started to PASS:

# taskset -c 1 ./poll02
tst_test.c:934: INFO: Timeout per run is 0h 05m 00s
tst_timer_test.c:356: INFO: CLOCK_MONOTONIC resolution 1ns
tst_timer_test.c:368: INFO: prctl(PR_GET_TIMERSLACK) = 50us
tst_timer_test.c:275: INFO: poll() sleeping for 1000us 500 iterations,
threshold 450.01us
tst_timer_test.c:318: INFO: min 1004us, max 1325us, median 1072us, trunc
mean 1149.29us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 2000us 500 iterations,
threshold 450.01us
tst_timer_test.c:318: INFO: min 2007us, max 2326us, median 2075us, trunc
mean 2158.64us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 5000us 300 iterations,
threshold 450.04us
tst_timer_test.c:318: INFO: min 5006us, max 5345us, median 5074us, trunc
mean 5146.84us (discarded 15)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 10000us 100 iterations,
threshold 450.33us
tst_timer_test.c:318: INFO: min 10004us, max 10364us, median 10075us, trunc
mean 10128.61us (discarded 5)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 25000us 50 iterations,
threshold 451.29us
tst_timer_test.c:318: INFO: min 25006us, max 25359us, median 25072us, trunc
mean 25137.48us (discarded 2)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 100000us 10 iterations,
threshold 537.00us
tst_timer_test.c:318: INFO: min 100010us, max 100372us, median 100125us,
trunc mean 100167.78us (discarded 1)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 1000000us 2 iterations,
threshold 4400.00us
tst_timer_test.c:318: INFO: min 1000843us, max 1000920us, median 1000843us,
trunc mean 1000843.00us (discarded 1)
tst_timer_test.c:333: PASS: Measured times are within thresholds

Summary:

passed   7
failed   0
skipped  0

Quoted 7 lines

warnings 0

Any ideas?

Regards,
Jan

--
<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

--
Mailing list info: https://lists.linux.it/listinfo/ltp

On Intel, the firmware usually overrides the kernel power management decision by auto-promoting the idle states.

So it is possible it is the case for you. With a process keeping the CPU "busy" that prevents the firmware to go to a deepest idle state.

I see it is a Xeon platform. You can try by checking the performance/power balance option in the BIOS. AFAIR, there is performance aggressive, power aggressive, balanced-performance+ and balanced-power+ and balanced.

Can you check this option ?

Quoted 145 lines

----- Original Message -----

Quoted 50 lines · Jan Stancek

Quoted 40 lines

Hi,

I'm running into similar problem on "Dell Precision 5820 tower", with Intel(R) Xeon(R) W-2133 CPU @ 3.60GHz, but I can't find any /proc /sys knob that would help.

# uname -r
4.14.5

# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance

Any timer related tests are reliably failing on longer timeouts:
---
tst_test.c:934: INFO: Timeout per run is 0h 05m 00s tst_timer_test.c:356: INFO: CLOCK_MONOTONIC resolution 1ns tst_timer_test.c:368: INFO: prctl(PR_GET_TIMERSLACK) = 50us tst_timer_test.c:275: INFO: poll() sleeping for 1000us 500 iterations, threshold 450.01us
tst_timer_test.c:318: INFO: min 1095us, max 1098us, median 1096us, trunc mean 1095.99us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 2000us 500 iterations, threshold 450.01us
tst_timer_test.c:318: INFO: min 2062us, max 2138us, median 2137us, trunc mean 2135.98us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 5000us 300 iterations, threshold 450.04us

Quoted 8 lines

tst_timer_test.c:318: INFO: min 5262us, max 5263us, median 5262us, trunc mean 5262.20us (discarded 15)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 10000us 100 iterations, threshold 450.33us
tst_timer_test.c:318: INFO: min 10318us, max 10471us, median 10471us, trunc mean 10469.07us (discarded 5)
tst_timer_test.c:321: FAIL: poll() slept for too long

Quoted 1 line

Are you running the tests with this zero latency patch included ?

Yes, I'm running ltp release 20170929, which has your patch.

...
[pid 18276] 09:59:21.379883 open("/dev/cpu_dma_latency", O_WRONLY) = 3 [pid 18276] 09:59:21.379906 write(3, "\0\0\0\0", 4) = 4
...

I tried it without that patch, and it started failing more with smaller timeouts.

Regards,
Jan

Quoted 77 lines

Quoted 57 lines

SCHED_OTHER or SCHED_FIFO -> FAIL intel_idle.max_cstate=0 processor.max_cstate=1 -> FAIL echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo -> FAIL idle=halt -> FAIL
idle=poll -> FAIL

Only thing I found to help is to keep CPU slightly busy with
taskset -c 1 sh -c "while [ True ]; do usleep 100; done"

After that it started to PASS:

# taskset -c 1 ./poll02
tst_test.c:934: INFO: Timeout per run is 0h 05m 00s
tst_timer_test.c:356: INFO: CLOCK_MONOTONIC resolution 1ns
tst_timer_test.c:368: INFO: prctl(PR_GET_TIMERSLACK) = 50us
tst_timer_test.c:275: INFO: poll() sleeping for 1000us 500 iterations,
threshold 450.01us
tst_timer_test.c:318: INFO: min 1004us, max 1325us, median 1072us, trunc
mean 1149.29us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 2000us 500 iterations,
threshold 450.01us
tst_timer_test.c:318: INFO: min 2007us, max 2326us, median 2075us, trunc
mean 2158.64us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 5000us 300 iterations,
threshold 450.04us
tst_timer_test.c:318: INFO: min 5006us, max 5345us, median 5074us, trunc
mean 5146.84us (discarded 15)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 10000us 100 iterations,
threshold 450.33us
tst_timer_test.c:318: INFO: min 10004us, max 10364us, median 10075us, trunc
mean 10128.61us (discarded 5)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 25000us 50 iterations,
threshold 451.29us
tst_timer_test.c:318: INFO: min 25006us, max 25359us, median 25072us, trunc
mean 25137.48us (discarded 2)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 100000us 10 iterations,
threshold 537.00us
tst_timer_test.c:318: INFO: min 100010us, max 100372us, median 100125us,
trunc mean 100167.78us (discarded 1)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 1000000us 2 iterations,
threshold 4400.00us
tst_timer_test.c:318: INFO: min 1000843us, max 1000920us, median 1000843us,
trunc mean 1000843.00us (discarded 1)
tst_timer_test.c:333: PASS: Measured times are within thresholds

Summary:

passed   7
failed   0
skipped  0

Quoted 7 lines

warnings 0

Any ideas?

Regards,
Jan

--
<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

--
Mailing list info: https://lists.linux.it/listinfo/ltp

Quoted 3 lines

On Intel, the firmware usually overrides the kernel power management decision by auto-promoting the idle states.

Quoted 4 lines

So it is possible it is the case for you. With a process keeping the CPU "busy" that prevents the firmware to go to a deepest idle state.

Quoted 6 lines

I see it is a Xeon platform. You can try by checking the performance/power balance option in the BIOS. AFAIR, there is performance aggressive, power aggressive, balanced-performance+ and balanced-power+ and balanced.

Can you check this option ?

So ? any news from the front ?

Quoted 143 lines · Jan Stancek

Quoted 141 lines

----- Original Message -----

Quoted 51 lines · Jan Stancek

Quoted 41 lines

Hi,

I'm running into similar problem on "Dell Precision 5820 tower", with Intel(R) Xeon(R) W-2133 CPU @ 3.60GHz, but I can't find any /proc /sys knob that would help.

# uname -r
4.14.5

# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance

Any timer related tests are reliably failing on longer timeouts:
---
tst_test.c:934: INFO: Timeout per run is 0h 05m 00s tst_timer_test.c:356: INFO: CLOCK_MONOTONIC resolution 1ns tst_timer_test.c:368: INFO: prctl(PR_GET_TIMERSLACK) = 50us tst_timer_test.c:275: INFO: poll() sleeping for 1000us 500 iterations, threshold 450.01us
tst_timer_test.c:318: INFO: min 1095us, max 1098us, median 1096us, trunc mean 1095.99us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 2000us 500 iterations, threshold 450.01us
tst_timer_test.c:318: INFO: min 2062us, max 2138us, median 2137us, trunc mean 2135.98us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 5000us 300 iterations, threshold 450.04us
tst_timer_test.c:318: INFO: min 5262us, max 5263us, median 5262us, trunc

Quoted 8 lines

mean 5262.20us (discarded 15)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 10000us 100 iterations, threshold 450.33us
tst_timer_test.c:318: INFO: min 10318us, max 10471us, median 10471us, trunc
mean 10469.07us (discarded 5)
tst_timer_test.c:321: FAIL: poll() slept for too long

Quoted 1 line

Are you running the tests with this zero latency patch included ?

Yes, I'm running ltp release 20170929, which has your patch.

...
[pid 18276] 09:59:21.379883 open("/dev/cpu_dma_latency", O_WRONLY) = 3 [pid 18276] 09:59:21.379906 write(3, "\0\0\0\0", 4) = 4
...

I tried it without that patch, and it started failing more with smaller timeouts.

Regards,
Jan

Quoted 72 lines

Quoted 60 lines

SCHED_OTHER or SCHED_FIFO -> FAIL intel_idle.max_cstate=0 processor.max_cstate=1 -> FAIL echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo -> FAIL idle=halt -> FAIL
idle=poll -> FAIL

Only thing I found to help is to keep CPU slightly busy with
taskset -c 1 sh -c "while [ True ]; do usleep 100; done"

After that it started to PASS:

# taskset -c 1 ./poll02
tst_test.c:934: INFO: Timeout per run is 0h 05m 00s
tst_timer_test.c:356: INFO: CLOCK_MONOTONIC resolution 1ns
tst_timer_test.c:368: INFO: prctl(PR_GET_TIMERSLACK) = 50us
tst_timer_test.c:275: INFO: poll() sleeping for 1000us 500 iterations,
threshold 450.01us
tst_timer_test.c:318: INFO: min 1004us, max 1325us, median 1072us, trunc
mean 1149.29us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 2000us 500 iterations,
threshold 450.01us
tst_timer_test.c:318: INFO: min 2007us, max 2326us, median 2075us, trunc
mean 2158.64us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 5000us 300 iterations,
threshold 450.04us
tst_timer_test.c:318: INFO: min 5006us, max 5345us, median 5074us, trunc
mean 5146.84us (discarded 15)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 10000us 100 iterations,
threshold 450.33us
tst_timer_test.c:318: INFO: min 10004us, max 10364us, median 10075us,
trunc
mean 10128.61us (discarded 5)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 25000us 50 iterations,
threshold 451.29us
tst_timer_test.c:318: INFO: min 25006us, max 25359us, median 25072us,
trunc
mean 25137.48us (discarded 2)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 100000us 10 iterations,
threshold 537.00us
tst_timer_test.c:318: INFO: min 100010us, max 100372us, median 100125us,
trunc mean 100167.78us (discarded 1)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 1000000us 2 iterations,
threshold 4400.00us
tst_timer_test.c:318: INFO: min 1000843us, max 1000920us, median
1000843us,
trunc mean 1000843.00us (discarded 1)
tst_timer_test.c:333: PASS: Measured times are within thresholds

Summary:

passed   7
failed   0
skipped  0

Quoted 7 lines

warnings 0

Any ideas?

Regards,
Jan

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

Quoted 10 lines

Quoted 8 lines

Quoted 8 lines

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

--
Mailing list info: https://lists.linux.it/listinfo/ltp

--
<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

On Intel, the firmware usually overrides the kernel power management decision by auto-promoting the idle states.

So it is possible it is the case for you. With a process keeping the CPU "busy" that prevents the firmware to go to a deepest idle state.

I see it is a Xeon platform. You can try by checking the performance/power balance option in the BIOS. AFAIR, there is performance aggressive, power aggressive, balanced-performance+ and balanced-power+ and balanced.

Can you check this option ?

Quoted 136 lines

----- Original Message -----

Quoted 51 lines · Jan Stancek

Quoted 41 lines

Hi,

I'm running into similar problem on "Dell Precision 5820 tower", with Intel(R) Xeon(R) W-2133 CPU @ 3.60GHz, but I can't find any /proc /sys knob that would help.

# uname -r
4.14.5

# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance

Any timer related tests are reliably failing on longer timeouts:
---
tst_test.c:934: INFO: Timeout per run is 0h 05m 00s tst_timer_test.c:356: INFO: CLOCK_MONOTONIC resolution 1ns tst_timer_test.c:368: INFO: prctl(PR_GET_TIMERSLACK) = 50us tst_timer_test.c:275: INFO: poll() sleeping for 1000us 500 iterations, threshold 450.01us
tst_timer_test.c:318: INFO: min 1095us, max 1098us, median 1096us, trunc mean 1095.99us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 2000us 500 iterations, threshold 450.01us
tst_timer_test.c:318: INFO: min 2062us, max 2138us, median 2137us, trunc mean 2135.98us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 5000us 300 iterations, threshold 450.04us
tst_timer_test.c:318: INFO: min 5262us, max 5263us, median 5262us, trunc

Quoted 8 lines

mean 5262.20us (discarded 15)
tst_timer_test.c:333: PASS: Measured times are within thresholds tst_timer_test.c:275: INFO: poll() sleeping for 10000us 100 iterations, threshold 450.33us
tst_timer_test.c:318: INFO: min 10318us, max 10471us, median 10471us, trunc
mean 10469.07us (discarded 5)
tst_timer_test.c:321: FAIL: poll() slept for too long

Quoted 1 line

Are you running the tests with this zero latency patch included ?

Yes, I'm running ltp release 20170929, which has your patch.

...
[pid 18276] 09:59:21.379883 open("/dev/cpu_dma_latency", O_WRONLY) = 3 [pid 18276] 09:59:21.379906 write(3, "\0\0\0\0", 4) = 4
...

I tried it without that patch, and it started failing more with smaller timeouts.

Regards,
Jan

Quoted 67 lines

Quoted 67 lines

SCHED_OTHER or SCHED_FIFO -> FAIL intel_idle.max_cstate=0 processor.max_cstate=1 -> FAIL echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo -> FAIL idle=halt -> FAIL
idle=poll -> FAIL

Only thing I found to help is to keep CPU slightly busy with
taskset -c 1 sh -c "while [ True ]; do usleep 100; done"

After that it started to PASS:

# taskset -c 1 ./poll02
tst_test.c:934: INFO: Timeout per run is 0h 05m 00s
tst_timer_test.c:356: INFO: CLOCK_MONOTONIC resolution 1ns
tst_timer_test.c:368: INFO: prctl(PR_GET_TIMERSLACK) = 50us
tst_timer_test.c:275: INFO: poll() sleeping for 1000us 500 iterations,
threshold 450.01us
tst_timer_test.c:318: INFO: min 1004us, max 1325us, median 1072us, trunc
mean 1149.29us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 2000us 500 iterations,
threshold 450.01us
tst_timer_test.c:318: INFO: min 2007us, max 2326us, median 2075us, trunc
mean 2158.64us (discarded 25)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 5000us 300 iterations,
threshold 450.04us
tst_timer_test.c:318: INFO: min 5006us, max 5345us, median 5074us, trunc
mean 5146.84us (discarded 15)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 10000us 100 iterations,
threshold 450.33us
tst_timer_test.c:318: INFO: min 10004us, max 10364us, median 10075us,
trunc
mean 10128.61us (discarded 5)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 25000us 50 iterations,
threshold 451.29us
tst_timer_test.c:318: INFO: min 25006us, max 25359us, median 25072us,
trunc
mean 25137.48us (discarded 2)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 100000us 10 iterations,
threshold 537.00us
tst_timer_test.c:318: INFO: min 100010us, max 100372us, median 100125us,
trunc mean 100167.78us (discarded 1)
tst_timer_test.c:333: PASS: Measured times are within thresholds
tst_timer_test.c:275: INFO: poll() sleeping for 1000000us 2 iterations,
threshold 4400.00us
tst_timer_test.c:318: INFO: min 1000843us, max 1000920us, median
1000843us,
trunc mean 1000843.00us (discarded 1)
tst_timer_test.c:333: PASS: Measured times are within thresholds

Summary:

passed   7
failed   0
skipped  0

warnings 0

Any ideas?

Regards,
Jan