The sched monitor page was linking to Daniel's website which is now
down. The main purpose of the link was to point to a source for the
models from the original author and that can be found also in his
published paper.

Replace the link with a reference to Daniel's "A thread synchronization
model for the PREEMPT_RT Linux kernel" which can be found online and
includes the models definitions as well as the work behind them (not the
original patches but since they're based on a 5.0 kernel and are mostly
included upstream, there's little value in keeping them in the docs).

Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
---
 Documentation/trace/rv/monitor_sched.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/trace/rv/monitor_sched.rst b/Documentation/trace/rv/monitor_sched.rst
index 0b96d6e147c6..661171bd7c5e 100644
--- a/Documentation/trace/rv/monitor_sched.rst
+++ b/Documentation/trace/rv/monitor_sched.rst
@@ -365,4 +365,4 @@ constraints when processing the events::
 References
 ----------
 
-[1] - https://bristot.me/linux-task-model
+[1] - Daniel Bristot de Oliveira et al.: A thread synchronization model for the PREEMPT_RT Linux kernel, J. Syst. Archit., 2020.

base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
-- 
2.53.0

Gabriele Monaco <gmonaco@redhat.com> writes:

> The sched monitor page was linking to Daniel's website which is now
> down. The main purpose of the link was to point to a source for the
> models from the original author and that can be found also in his
> published paper.
>
> Replace the link with a reference to Daniel's "A thread synchronization
> model for the PREEMPT_RT Linux kernel" which can be found online and
> includes the models definitions as well as the work behind them (not the
> original patches but since they're based on a 5.0 kernel and are mostly
> included upstream, there's little value in keeping them in the docs).
>
> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
> ---
>  Documentation/trace/rv/monitor_sched.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/trace/rv/monitor_sched.rst b/Documentation/trace/rv/monitor_sched.rst
> index 0b96d6e147c6..661171bd7c5e 100644
> --- a/Documentation/trace/rv/monitor_sched.rst
> +++ b/Documentation/trace/rv/monitor_sched.rst
> @@ -365,4 +365,4 @@ constraints when processing the events::
>  References
>  ----------
>  
> -[1] - https://bristot.me/linux-task-model
> +[1] - Daniel Bristot de Oliveira et al.: A thread synchronization model for the PREEMPT_RT Linux kernel, J. Syst. Archit., 2020.

Since, as you say, it can be found online, is there a reason not to
include a link here?

jon

On Mon, 2026-04-27 at 03:44 -0600, Jonathan Corbet wrote:
> Since, as you say, it can be found online, is there a reason not to
> include a link here?

Mmh, perhaps being overly cautious for the link not to break again?

The paper is published so I assume it's always going to be available in
some way. It is currently hosted by the university at [1], which may be
unlikely to change, and can be found via DOI at [2], which should never
change (at least that's what I believe a DOI is for) but brings to the
publisher's website rather than the open-access PDF.

I think the reference to the paper I included is robust yet easy to use
with any scientific or even general purpose search engine. But if you
believe using either of the two links is more appropriate, I can send a
V2 with the change.

Thanks,
Gabriele

[1] -
https://www.iris.sssup.it/bitstream/11382/533630/1/Elsevier-JSA-2020.pdf
[2] - https://doi.org/10.1016/j.sysarc.2020.101729

Gabriele Monaco <gmonaco@redhat.com> writes:

> On Mon, 2026-04-27 at 03:44 -0600, Jonathan Corbet wrote:
>> Since, as you say, it can be found online, is there a reason not to
>> include a link here?
>
> Mmh, perhaps being overly cautious for the link not to break again?
>
> The paper is published so I assume it's always going to be available in
> some way. It is currently hosted by the university at [1], which may be
> unlikely to change, and can be found via DOI at [2], which should never
> change (at least that's what I believe a DOI is for) but brings to the
> publisher's website rather than the open-access PDF.
>
> I think the reference to the paper I included is robust yet easy to use
> with any scientific or even general purpose search engine. But if you
> believe using either of the two links is more appropriate, I can send a
> V2 with the change.

I will defer to others in the end, but to me it seems that we should
make life easier for our readers whenever we can.  Providing a link
seems better than requiring them to search for it themselves.

Thanks,

jon

On Mon, 2026-04-27 at 04:09 -0600, Jonathan Corbet wrote:
> Gabriele Monaco <gmonaco@redhat.com> writes:
> 
> > On Mon, 2026-04-27 at 03:44 -0600, Jonathan Corbet wrote:
> > > Since, as you say, it can be found online, is there a reason not
> > > to include a link here?
> > 
> > Mmh, perhaps being overly cautious for the link not to break again?
> > 
> > The paper is published so I assume it's always going to be
> > available in some way. It is currently hosted by the university at
> > [1], which may be unlikely to change, and can be found via DOI at
> > [2], which should never change (at least that's what I believe a
> > DOI is for) but brings to the publisher's website rather than the
> > open-access PDF.
> > 
> > I think the reference to the paper I included is robust yet easy to
> > use with any scientific or even general purpose search engine. But
> > if you believe using either of the two links is more appropriate, I
> > can send a V2 with the change.
> 
> I will defer to others in the end, but to me it seems that we should
> make life easier for our readers whenever we can.  Providing a link
> seems better than requiring them to search for it themselves.

Alright, makes sense. I'm going to send a V2 with [1] (the open access
PDF), in the remote case the link stops working, we can update it.

Thanks,
Gabriele

On Mon, 27 Apr 2026 14:56:46 +0200
Gabriele Monaco <gmonaco@redhat.com> wrote:

> > 
> > I will defer to others in the end, but to me it seems that we should
> > make life easier for our readers whenever we can.  Providing a link
> > seems better than requiring them to search for it themselves.  
> 
> Alright, makes sense. I'm going to send a V2 with [1] (the open access
> PDF), in the remote case the link stops working, we can update it.

Can you add both?

[1] - Daniel Bristot de Oliveira et al.: A thread synchronization model for the PREEMPT_RT Linux kernel, J. Syst. Archit., 2020.
      https://www.iris.sssup.it/bitstream/11382/533630/1/Elsevier-JSA-2020.pdf

 ?

-- Steve