All of lore.kernel.org
 help / color / mirror / Atom feed
From: Punit Agrawal <punitagrawal@gmail.com>
To: Pierre FICHEUX <pierre.ficheux@smile.fr>
Cc: linux-rt-users@vger.kernel.org
Subject: Re: Strange problem with PREEMPT_RT
Date: Thu, 30 Sep 2021 09:13:25 +0900	[thread overview]
Message-ID: <87y27e53a2.fsf@stealth> (raw)
In-Reply-To: <CAFc1U0sgMtKvcpTWkyjwXsq3Md_Huew7mSye_AratkM63D6K-Q@mail.gmail.com> (Pierre FICHEUX's message of "Wed, 29 Sep 2021 18:40:35 +0200")

Pierre FICHEUX <pierre.ficheux@smile.fr> writes:

> Hi,
>
> I have a strange problem on a PREEMPT_RT system.
>
> I have a process with 2 threads,
>
> - 1 TR thread (10 ms period) which places 350 KB blocks in a fifo (1
> block every 10 ms).
> - 1 non-TR thread (SCHED_OTHER) which reads the block in the fifo and
> writes it to the disk
>
> If I run this on a powerful machine (HP Z4-i9, 14 cores, NVME disk,
> CentOS 7 with 3.10 PREEMPT_RT kernel, yes that's ooold), the max
> jitter WITH hackbench remains around 20 to 30 µs while the max jitter
> WITHOUT hackbench goes up to 350 µs!
>
> -> hackbench -p -g 20 -l 10000000
>
> Running the program with  taskset 01 doesn't change anything
> If I don't write the data to disk it doesn't change anything either.
>
> The important jitters appear rather at the beginning (but sometimes also later).
>
> Any ideas ?

Is power management (cpuidle, cpufreq) enabled on the system?

One possible explanation -

The load from the 10ms task, isn't high enough to keep the system at
high-frequencies or prevent it from going into deeper sleep states. Both
of these can impact latencies.

With hackbench, the system is sufficiently busy to avoid the going into
idle.

>
>
> thanks by advance
>
> --
> Pierre

  reply	other threads:[~2021-09-30  0:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-29 16:40 Strange problem with PREEMPT_RT Pierre FICHEUX
2021-09-30  0:13 ` Punit Agrawal [this message]
2021-09-30  8:21   ` Pierre FICHEUX
2021-09-30 13:17     ` Luis Goncalves
2021-09-30 13:18     ` Sebastian Andrzej Siewior
2021-09-30 13:23   ` Sebastian Andrzej Siewior
2021-09-30 13:26     ` Pierre FICHEUX
2021-09-30 13:51       ` Sebastian Andrzej Siewior
2021-09-30 14:31         ` Pierre FICHEUX
2021-09-30 23:40           ` Punit Agrawal
2021-10-03 11:11             ` Jack Winch
2021-10-04 12:54               ` John Kacur
2021-10-18  9:12           ` Sebastian Andrzej Siewior
2021-09-30 13:41     ` John Ogness
2021-09-30 14:25       ` John Kacur
2021-09-30 15:02         ` John Ogness
2021-09-30 15:49           ` Sebastian Andrzej Siewior
2021-09-30 16:16           ` John Kacur
2021-09-30 23:22             ` Punit Agrawal
2021-09-30 14:59       ` John Kacur
2021-09-30 23:01     ` Punit Agrawal

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=87y27e53a2.fsf@stealth \
    --to=punitagrawal@gmail.com \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=pierre.ficheux@smile.fr \
    /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.