All of lore.kernel.org
 help / color / mirror / Atom feed
From: luca abeni <luca.abeni@santannapisa.it>
To: Juri Lelli <juri.lelli@redhat.com>
Cc: Marcel Ziswiler <marcel.ziswiler@codethink.co.uk>,
	<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: Tue, 24 Jun 2025 15:36:33 +0200	[thread overview]
Message-ID: <20250624153633.6cb8dde8@nowhere> (raw)
In-Reply-To: <20250620185248.634101cc@nowhere>

On Fri, 20 Jun 2025 18:52:48 +0200
luca abeni <luca.abeni@santannapisa.it> wrote:
[...]
> > >   should be decreased by Ui when a task with utilization Ui
> > > becomes SCHED_DEADLINE (and increased by Ui when the
> > > SCHED_DEADLINE task terminates or changes scheduling policy).
> > > Since this value is per_core, Ui is divided by the number of
> > > cores in the root domain... From what you write, I guess extra_bw
> > > is not correctly initialized/updated when a new root domain is
> > > created?    
> > 
> > It looks like so yeah. After boot and when domains are dinamically
> > created. But, I am still not 100%, I only see weird numbers that I
> > struggle to relate with what you say above. :)  
> 
> BTW, when running some tests on different machines I think I found out
> that 6.11 does not exhibit this issue (this needs to be confirmed, I
> am working on reproducing the test with different kernels on the same
> machine)
> 
> If I manage to reproduce this result, I think I can run a bisect to
> the commit introducing the issue (git is telling me that I'll need
> about 15 tests :)
> So, stay tuned...

It took more than I expected, but I think I found the guilty commit...
It seems to be
[5f6bd380c7bdbe10f7b4e8ddcceed60ce0714c6d] sched/rt: Remove default bandwidth control

Starting from this commit, I can reproduce the issue, but if I test the
previous commit (c8a85394cfdb4696b4e2f8a0f3066a1c921af426
sched/core: Fix picking of tasks for core scheduling with DL server)
the issue disappears.

Maybe this information can help in better understanding the problem :)



			Luca

> 
> > > All this information is probably not properly documented...
> > > Should I improve the description in
> > > Documentation/scheduler/sched-deadline.rst or do you prefer some
> > > comments in kernel/sched/deadline.c? (or .h?)    
> > 
> > I think ideally both. sched-deadline.rst should probably contain the
> > whole picture with more information and .c/.h the condendensed
> > version.  
> 
> OK, I'll try to do this in next week
> 
> 
> 			Thanks,
> 				Luca


  parent reply	other threads:[~2025-06-24 13:36 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
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 [this message]
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=20250624153633.6cb8dde8@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.