All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.