2020-09-29 17:50:19 jkacur: one of the best things I ever read was written
by paulmck about how high priority threads should be high priority for the 
smallest time possible - but with the math to back it up, wish I knew what 
that paper was called or how to find it again.

2020-09-30 01:18:17 paulmck: jkacur: You might be remembering my 2011 
RTLWS presentation "On migrate_disable() and Latencies" which can be found 
here: http://www.rdrop.com/~paulmck/realtime/. But to peterz's point, 
there are much better source of that sort of information by now, perhaps 
most notably Daniel Bristot's work. And lots of other things as well, 
given the large and welcome increase in interest in analyzing the Linux 
kernel over the nine years since that talk. ;-)

Worth to be remembered 🙂

The Real-Time Mini-Summit is organized by the Linux Foundation Real-Time Linux (RTL) collaborative project. The event is intended to gather developers and users of Linux as a Real-Time Operating System. The main intent is to provide room for discussion between developers, tooling experts, and users.

The mini-summit will take place alongside the Open Source Summit + Embedded Linux Conference Europe 2020, virtually. The summit is planned last day of the main conference, Friday, October 30th, 2020.

If you are interested to present, please submit a proposal [1] before September 30th, 2020, at 23:59 EST. Please provide a title, an abstract describing the proposed talk, a short biography, and describe the targeted audience. Please indicate the slot length you are aiming for: The format is a single track with presentation slots of 15, 30 minutes long. Considering that the presentation should leave a space for discussion.

We are welcoming presentations from both end-users and developers, on topics covering, but not limited to:

• Real-time Linux development
• Real-time Linux evaluation
• Real-time Linux use cases (Success and failures)
• Real-time Linux tooling (tracing, configuration, …)
• Real-time Linux academic work, already presented or under development, for direct feedback from practitioners community.
• Those can cover recently available technologies, ongoing work, and new ideas.

Important Notes for Speakers:

All speakers are required to adhere to the Linux Foundation events’ Code of Conduct. We also highly recommend that speakers take the Linux Foundation online Inclusive Speaker Orientation Course. Avoid sales or marketing pitches and discussing unlicensed or potentially closed-source technologies when preparing your proposal; these talks are almost always rejected due to the fact that they take away from the integrity of our events, and are rarely well-received by conference attendees.

All accepted speakers are required to submit their slides prior to the event.

[1] Submission page: https://forms.gle/yQeqyrtJYezM5VRJA

Important Dates:

CFP Close: Wednesday, September 30th, 2020, at 23:59 PST
Speaker notification: October 10th, 2020
Conference: Friday, October 30th, 2020

Questions on submitting a proposal?
Email Daniel Bristot de Oliveira <bristot@redhat.com>

Earlier this week I was debugging a SCHED_DEADLINE related bug, and Juri pointed me (on IRC) to a patch that was recently sent to the LKML that could potentiation fix the problem. I did not know about that patch because it is hard to follow everything that passes through LKML. To avoid missing these points, we ended up agreeing on adding me as a reviewer for SCHED_DEADLINE!

The request was well received by the other maintainers, Peter Z. said:

Absolutely, great to have you looking over that!

Juri said:

Thanks for the help Daniel!

Acked-by: Juri Lelli <juri.lelli@redhat.com>

Best,
Juri

And Ingo:

Welcome Daniel! :-)

I've applied the patch to tip:sched/core.

Thanks,

	Ingo

Juri later recalled me that “you will have more work to do”… and I replied: well, this is the kind of work I like to do :-).

Due to COVID 19 restrictions, I had to make my Ph.D. defense entirely online. Yes, that was not the way I would like to do it, but in the end, it turned possible for many people to attend it, including my mother that was down there in Brazil. Here is the recordings of my thesis defense:

My thesis manuscript is here!

This is the call for proposals for the Real-Time Micro Conference at the Linux Plumbers Conference 2020. It will take place online during the Linux Plumbers Conference on August 24th-28th, 2020.

The real-time micro-conference targets discussions about new features or open problems related to real-time Linux. Each accepted topic will receive a 30 minutes slot. The presenter – or mediator – will introduce the problem in the first 10 minutes with a short presentation and then promotes the discussion in the next 20 minutes.

We encourage submissions that do not present a final solution. Instead, that serves to get feedback from the community, to point to action items for future development, and that can result in patches for the real-time Linux eco-system in the future.

Please submit your proposals on the LPC website at:

https://www.linuxplumbersconf.org/event/7/abstracts/#submit-abstract

And be sure to select “Real-time MC” in the Track pulldown menu.

Proposals must be submitted by August 2nd, and submitters will be notified of acceptance by August 9th.

About the real-time MC:

Since 2004 a project has improved the Real-time and low-latency features for Linux. This project has become know as PREEMPT_RT, formally the real-time patch. Over the past decade, many parts of the PREEMPT RT became part of the official Linux codebase. Examples of what came from PREEMPT_RT include: Mutexes, high-resolution timers, lockdep, ftrace, RT scheduling, SCHED_DEADLINE, RCU_PREEMPT, generic interrupts, priority inheritance futexes, threaded interrupt handlers and more. The number of patches that needs integration has been reduced in the last years, and the pieces left are now mature enough to make its way into mainline Linux. For real, this year could possibly be the year PREEMPT_RT is merged™!

In the final lap of this race, the last patches are on the way to be merged, but there are still some very few pieces missing. When the merge occurs, the PREEMPT_RT will start to follow a new pace: the Linus one. So, it is possible to raise the following discussions:

• The status of the merge, and how can we resolve the last issues that block the merge;
• How can we improve the testing of the -rt, to follow the problems raised as Linus tree advances;
• What’s next?

Other possible topics:

• Merge – what is missing and who can help?
• New tools for PREEMPT_RT analysis.
• How do we teach the rest of the kernel developers how not to break PREEMPT_RT?
• Stable maintainers tools discussion & improvements.
• The usage of PREEMPT_RT on safety critical-systems: what do we need to do?
• Interrupt threads are RT and are not protected by the RT Throttling.
• How can we prevent interrupt thread starvation from a rogue RT task?

If your topic is not listed here, it is a good sign that you need to propose your talk! This micro-conference is about new things, not things that people already know, so go ahead and fill a proposal!

If you have any further doubt, feel free to contact me via email to bristot@redhat.com.

“Frege formulated the idea of a formal system, in which one defines in advance all the allowable symbols, all the rules that produce well-formed formulas, all axioms (i.e., certain preselected, well-formed formulas), and all the rules of inference. In such systems any deduction can be checked syntactically —in other words, by purely symbolic means. On the basis of such systems Frege aimed to produce theories with no logical gaps in their proofs.“

mental note:

lvextend -l +100%FREE -r /dev/VG/LV

this is just a memory note, do not expect explanations.

With the VM off, dump its config:

# virsh dumpxml f31-x64-inheritance > inheritance

Then, bellow:

<vcpu placement="static">4</vcpu>

add these parameters to set the priority FIFO 1, and pin one vCPU to one CPU:

  <cputune>
    <vcpusched vcpus='0-3' scheduler='fifo' priority='1'/>
    <vcpupin vcpu='0' cpuset='4'/>
    <vcpupin vcpu='1' cpuset='5'/>
    <vcpupin vcpu='2' cpuset='6'/>
    <vcpupin vcpu='3' cpuset='7'/>
  </cputune>

and reload the config:

# virsh define inheritance        

•