All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH V3] ltp: Add a zero latency constraint for the timer tests library
Date: Tue, 12 Dec 2017 16:21:35 +0100	[thread overview]
Message-ID: <0dd9434e-01b0-e7dd-9984-f787a1a08d99@linaro.org> (raw)
In-Reply-To: <1566390724.54053292.1513091073892.JavaMail.zimbra@redhat.com>


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 ?

On 12/12/2017 16:04, Jan Stancek wrote:
> 
> 
> ----- Original Message -----
>> On 12/12/2017 15:48, Jan Stancek wrote:
>>> 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
>>
>> 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
> 
>>
>>
>>> 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
>>>
>>
>>
>> --
>>  <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
>>


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


  reply	other threads:[~2017-12-12 15:21 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-10  8:01 [LTP] [PATCH 1/2] ltp: Add the ability to specify the latency constraint Daniel Lezcano
2017-08-10  8:01 ` [LTP] [PATCH 2/2] syscalls/pselect: Add a zero " Daniel Lezcano
2017-08-10 11:50   ` Jiri Jaburek
2017-08-10 12:00     ` Daniel Lezcano
2017-08-11 11:26       ` Jan Stancek
2017-08-11 11:25 ` [LTP] [PATCH 1/2] ltp: Add the ability to specify the " Jan Stancek
2017-08-11 12:54   ` [LTP] [PATCH V2 " Daniel Lezcano
2017-08-11 12:54     ` [LTP] [PATCH V2 2/2] syscalls/pselect: Add a zero " Daniel Lezcano
2017-08-11 14:09     ` [LTP] [PATCH V2 1/2] ltp: Add the ability to specify the " Cyril Hrubis
2017-08-11 14:52       ` Daniel Lezcano
2017-08-11 15:28         ` Cyril Hrubis
2017-08-14 12:56           ` Daniel Lezcano
2017-08-14 13:33             ` Cyril Hrubis
2017-08-14 14:19               ` Daniel Lezcano
2017-08-14 14:36                 ` Cyril Hrubis
2017-08-14 15:43                   ` Daniel Lezcano
2017-08-15 11:06                     ` Cyril Hrubis
2017-08-15 20:15                       ` Daniel Lezcano
2017-08-17 13:50                         ` Cyril Hrubis
2017-08-17 14:02                           ` Daniel Lezcano
2017-08-17 15:00                           ` [LTP] [PATCH V3] ltp: Add a zero latency constraint for the timer tests library Daniel Lezcano
2017-08-18 12:25                             ` Cyril Hrubis
2017-12-12 14:48                               ` Jan Stancek
2017-12-12 14:56                                 ` Daniel Lezcano
2017-12-12 15:04                                   ` Jan Stancek
2017-12-12 15:21                                     ` Daniel Lezcano [this message]
2017-12-13 17:00                                       ` Daniel Lezcano
2017-12-13 20:42                                         ` Jan Stancek
2018-02-01 22:52                                       ` Jan Stancek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0dd9434e-01b0-e7dd-9984-f787a1a08d99@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.