All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: Li Wang <liwang@redhat.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2] sched_football: synchronize with kickoff flag to reduce skew
Date: Fri, 5 Sep 2025 11:18:46 +0200	[thread overview]
Message-ID: <aLqq9o9Dkbhr957V@yuki.lan> (raw)
In-Reply-To: <CAEemH2cXQ=_F=Bq5CZN1j=SbeceDCKCdZh4jDdGSz-x10XZLtA@mail.gmail.com>

Hi!
> Checking the configurations of the stock kernel and the real-time
> kernel, the stock kernel uses "CONFIG_PREEMPT_VOLUNTARY=y,"
> which only provides voluntary preemption.
>
> This preemption model is designed to strike a balance between throughput
> and latency. It only allows the kernel to be preempted at specific, well
> defined
> "safe points," potentially resulting in long, unbounded latencies.
> 
> However, the sched_football test was most likely designed to measure or
> stress-test the deterministic, low-latency scheduling behavior that is
> characteristic of real-time (RT) kernel.
> 
> So, I tend to believe the test's failure on the stock kernel is acceptable.

I still find it a bit unexpected though. The preeption models apply only
to kernel code. The user space code can be stil preempted at any point,
so the offense threads should be preempted and replaced by high priority
tasks and never executed again since we do not call to the kernel there
at all, we just run a loop that increments an integer there. I guess
that one possibility is that we saturate the machine with real-time
tasks to the extend that scheduller code in kernel does not get to
distribute the processes. If that is a problem we need to give kernel
chance to shuffle the processes when we wait for the kickoff flag.

Does things start to work if we change the loops that wait for the final
kickoff to:

       while (!tst_atomic_load(&kickoff_flag))
               sched_yield();

This should trigger the scheduller code to be executed so that it has
chance to distribute the processes around.

-- 
Cyril Hrubis
chrubis@suse.cz

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

  parent reply	other threads:[~2025-09-05  9:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-04 10:26 [LTP] [PATCH v2] sched_football: synchronize with kickoff flag to reduce skew Li Wang via ltp
2025-09-04 11:00 ` Petr Vorel
2025-09-04 11:42   ` Cyril Hrubis
2025-09-04 13:14     ` Li Wang via ltp
2025-09-04 15:28       ` Cyril Hrubis
2025-09-05  0:54         ` Li Wang via ltp
2025-09-05  4:03           ` Li Wang via ltp
2025-09-05  6:50             ` Li Wang via ltp
2025-09-05  7:03             ` Petr Vorel
2025-09-05  7:31               ` Petr Vorel
2025-09-05  7:36                 ` Li Wang via ltp
2025-09-05  9:18             ` Cyril Hrubis [this message]
2025-09-05 11:50               ` Li Wang via ltp
2025-09-05 12:32                 ` Cyril Hrubis
2025-09-05 12:46                   ` Petr Vorel
2025-09-06  0:58                     ` Li Wang via ltp
2025-09-05 12:49                   ` Li Wang via ltp
2025-09-05 13:45                     ` Cyril Hrubis
2025-09-05 14:48                       ` Li Wang via ltp
2025-09-04 18:26       ` Petr Vorel

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=aLqq9o9Dkbhr957V@yuki.lan \
    --to=chrubis@suse.cz \
    --cc=liwang@redhat.com \
    --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.