From: luca abeni <luca.abeni@santannapisa.it>
To: Marcel Ziswiler <marcel.ziswiler@codethink.co.uk>
Cc: Juri Lelli <juri.lelli@redhat.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Vineeth Pillai <vineeth@bitbyteword.org>
Subject: Re: SCHED_DEADLINE tasks missing their deadline with SCHED_FLAG_RECLAIM jobs in the mix (using GRUB)
Date: Wed, 7 May 2025 22:25:49 +0200 [thread overview]
Message-ID: <20250507222549.183e0b4a@nowhere> (raw)
In-Reply-To: <f532441d8b3cf35e7058305fd9cd3f2cbd3a9fac.camel@codethink.co.uk>
Hi Marcel,
just a quick question to better understand your setup (and check where
the issue comes from):
in the email below, you say that tasks are statically assigned to
cores; how did you do this? Did you use isolated cpusets, or did you
set the tasks affinities after disabling the SCHED_DEADLINE admission
control (echo -1 > /proc/sys/kernel/sched_rt_runtime_us)?
Or am I misunderstanding your setup?
Also, are you using HRTICK_DL?
Thanks,
Luca
On Sat, 03 May 2025 13:14:53 +0200
Marcel Ziswiler <marcel.ziswiler@codethink.co.uk> wrote:
[...]
> We currently use three cores as follows:
>
> #### core x
>
> |sched_deadline = sched_period | sched_runtime | CP max run time 90%
> of sched_runtime | utilisation | reclaim | | -- | -- | -- | -- | -- |
> | 5 ms | 0.15 ms | 0.135 ms | 3.00% | no |
> | 10 ms | 1.8 ms | 1.62 ms | 18.00% | no |
> | 10 ms | 2.1 ms | 1.89 ms | 21.00% | no |
> | 14 ms | 2.3 ms | 2.07 ms | 16.43% | no |
> | 50 ms | 8.0 ms | 7.20 ms | 16:00% | no |
> | 10 ms | 0.5 ms | **1 | 5.00% | no |
>
> Total utilisation of core x is 79.43% (less than 100%)
>
> **1 - this shall be a rogue process. This process will
> a) run for the maximum allowed workload value
> b) do not collect execution data
>
> This last rogue process is the one which causes massive issues to the
> rest of the scheduling if we set it to do reclaim.
>
> #### core y
>
> |sched_deadline = sched_period | sched_runtime | CP max run time 90%
> of sched_runtime | utilisation | reclaim | | -- | -- | -- | -- | -- |
> | 5 ms | 0.5 ms | 0.45 ms | 10.00% | no |
> | 10 ms | 1.9 ms | 1.71 ms | 19.00% | no |
> | 12 ms | 1.8 ms | 1.62 ms | 15.00% | no |
> | 50 ms | 5.5 ms | 4.95 ms | 11.00% | no |
> | 50 ms | 9.0 ms | 8.10 ms | 18.00% | no |
>
> Total utilisation of core y is 73.00% (less than 100%)
>
> #### core z
>
> The third core is special as it will run 50 jobs with the same
> configuration as such:
>
> |sched_deadline = sched_period | sched_runtime | CP max run time 90%
> of sched_runtime | utilisation | | -- | -- | -- | -- |
> | 50 ms | 0.8 ms | 0.72 ms | 1.60% |
>
> jobs 1-50 should run with reclaim OFF
>
> Total utilisation of core y is 1.6 * 50 = 80.00% (less than 100%)
>
> Please let me know if you need any further details which may help
> figuring out what exactly is going on.
>
> > Adding Luca in Cc so he can also take a look.
> >
> > Thanks,
>
> Thank you!
>
> > Juri
>
> Cheers
>
> Marcel
next prev parent reply other threads:[~2025-05-07 20:25 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-28 18:04 SCHED_DEADLINE tasks missing their deadline with SCHED_FLAG_RECLAIM jobs in the mix (using GRUB) Marcel Ziswiler
2025-05-02 13:55 ` Juri Lelli
2025-05-02 14:10 ` luca abeni
2025-05-03 13:14 ` Marcel Ziswiler
2025-05-05 15:53 ` luca abeni
2025-05-03 11:14 ` Marcel Ziswiler
2025-05-07 20:25 ` luca abeni [this message]
2025-05-19 13:32 ` Marcel Ziswiler
2025-05-20 16:09 ` luca abeni
2025-05-21 9:59 ` Marcel Ziswiler
2025-05-23 19:46 ` luca abeni
2025-05-25 19:29 ` Marcel Ziswiler
2025-05-29 9:39 ` Juri Lelli
2025-06-02 14:59 ` Marcel Ziswiler
2025-06-17 12:21 ` Juri Lelli
2025-06-18 11:24 ` Marcel Ziswiler
2025-06-20 9:29 ` Juri Lelli
2025-06-20 9:37 ` luca abeni
2025-06-20 9:58 ` Juri Lelli
2025-06-20 14:16 ` luca abeni
2025-06-20 15:28 ` Juri Lelli
2025-06-20 16:52 ` luca abeni
2025-06-24 7:49 ` Juri Lelli
2025-06-24 12:59 ` Juri Lelli
2025-06-24 15:00 ` luca abeni
2025-06-25 9:30 ` Juri Lelli
2025-06-25 10:11 ` Juri Lelli
2025-06-25 12:50 ` luca abeni
2025-06-26 10:59 ` Marcel Ziswiler
2025-06-26 11:45 ` Juri Lelli
2025-06-25 15:55 ` Marcel Ziswiler
2025-06-24 13:36 ` luca abeni
2025-05-30 9:21 ` luca abeni
2025-06-03 11:18 ` Marcel Ziswiler
2025-06-06 13:16 ` luca abeni
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=20250507222549.183e0b4a@nowhere \
--to=luca.abeni@santannapisa.it \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel.ziswiler@codethink.co.uk \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=vineeth@bitbyteword.org \
/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.