All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Li Wang <liwang@redhat.com>, Cyril Hrubis <chrubis@suse.cz>,
	ltp@lists.linux.it, Andrea Cervesato <andrea.cervesato@suse.com>,
	Chunyu Hu <chuhu@redhat.com>
Subject: Re: [LTP] [PATCH v2] sched_football: synchronize with kickoff flag to reduce skew
Date: Fri, 5 Sep 2025 09:31:27 +0200	[thread overview]
Message-ID: <20250905073127.GA16065@pevik> (raw)
In-Reply-To: <20250905070312.GA4185@pevik>

> Hi all,

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

> Yes, CONFIG_PREEMPT_VOLUNTARY=y is in all mainline defconfigs
> (arch/*/configs/*_defconfig). Therefore we have it in our Tumbleweed (6.16.3-1)
> and in upcoming SLES16 (6.12 based). SLE15-SP7 (6.4 based) use
> CONFIG_PREEMPT_NONE=y instead.

> Looking at the history It works well on all archs, we just recently had a
> problem with ppc64le hmc on SLE16 (regular ppc64le works). Later I'll check
> history of older SLES versions.

> And most importantly I'll try to run manually with -i (more stress test).

> > 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.
> > And, by the way, what does the SUSE kernel configuration look like?


> > # grep CONFIG_PREEMPT /boot/config-6.12.0-55.29.1.el10_0.x86_64
> > CONFIG_PREEMPT_BUILD=y
> > CONFIG_PREEMPT_VOLUNTARY=y
> > # CONFIG_PREEMPT is not set
> > # CONFIG_PREEMPT_RT is not set
> > CONFIG_PREEMPT_COUNT=y
> > CONFIG_PREEMPTION=y
> > CONFIG_PREEMPT_DYNAMIC=y
> > CONFIG_PREEMPT_RCU=y
> > CONFIG_PREEMPT_NOTIFIERS=y

> > (^ I built my v6.17-rc4 with this config too)

> /boot/config-6.12.0-160000.4-default # Tumbleweed x68_64
> CONFIG_PREEMPT_BUILD=y
> # CONFIG_PREEMPT_NONE is not set
> CONFIG_PREEMPT_VOLUNTARY=y
> # CONFIG_PREEMPT is not set
> # CONFIG_PREEMPT_LAZY is not set
> # CONFIG_PREEMPT_RT is not set
> CONFIG_PREEMPT_COUNT=y
> CONFIG_PREEMPTION=y
> CONFIG_PREEMPT_DYNAMIC=y
> CONFIG_PREEMPT_RCU=y
> CONFIG_PREEMPT_NOTIFIERS=y
> # CONFIG_PREEMPT_TRACER is not set
> CONFIG_PREEMPTIRQ_DELAY_TEST=m

> Upcoming SLE16 is similar to Tumbleweed.

> /boot/config-6.4.0-150700.714.ga8e7017-default # SLE15-SP7 x86_64 RT
> CONFIG_PREEMPT_BUILD=y
> CONFIG_PREEMPT_NONE=y
> # CONFIG_PREEMPT_VOLUNTARY is not set
> # CONFIG_PREEMPT is not set
> # CONFIG_PREEMPT_RT is not set
> CONFIG_PREEMPT_COUNT=y
> CONFIG_PREEMPTION=y
> CONFIG_PREEMPT_DYNAMIC=y
> CONFIG_PREEMPT_RCU=y
> CONFIG_PREEMPT_NOTIFIERS=y
> # CONFIG_PREEMPT_TRACER is not set
> CONFIG_PREEMPTIRQ_DELAY_TEST=m

> /boot/config-6.4.0-150700.5-rt # SLE15-SP7 x86_64 RT
> CONFIG_PREEMPT_LAZY=y
> # CONFIG_PREEMPT_NONE is not set
> # CONFIG_PREEMPT_VOLUNTARY is not set
> # CONFIG_PREEMPT is not set
> CONFIG_PREEMPT_RT=y
> CONFIG_PREEMPT_COUNT=y
> CONFIG_PREEMPTION=y
> CONFIG_PREEMPT_RCU=y
> CONFIG_PREEMPT_NOTIFIERS=y
> # CONFIG_PREEMPT_TRACER is not set
> CONFIG_PREEMPTIRQ_DELAY_TEST=m

And looking on some other distros, e.g. Debian had CONFIG_PREEMPT_VOLUNTARY=y on
6.12.38+deb13 (from recently released stable Debian 13 trixie), but they changed
it to CONFIG_PREEMPT_LAZY=y in 6.16.3+deb14 (for upcoming Debian forky (testing)
- in devel for now). I would expect that setup for RT kernel.

> Kind regards,
> Petr

> > # grep CONFIG_PREEMPT /boot/config-6.12.0-55.31.1.el10_0.x86_64+rt
> > CONFIG_PREEMPT_BUILD=y
> > CONFIG_PREEMPT=y
> > CONFIG_PREEMPT_RT=y
> > CONFIG_PREEMPT_COUNT=y
> > CONFIG_PREEMPTION=y
> > # CONFIG_PREEMPT_DYNAMIC is not set
> > CONFIG_PREEMPT_RCU=y
> > CONFIG_PREEMPT_NOTIFIERS=y

I suppose this RT kernel has CONFIG_PREEMPT_LAZY=y, right?

Kind regards,
Petr

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

  reply	other threads:[~2025-09-05  7:31 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 [this message]
2025-09-05  7:36                 ` Li Wang via ltp
2025-09-05  9:18             ` Cyril Hrubis
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=20250905073127.GA16065@pevik \
    --to=pvorel@suse.cz \
    --cc=andrea.cervesato@suse.com \
    --cc=chrubis@suse.cz \
    --cc=chuhu@redhat.com \
    --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.