 Yeah, we better start. Thanks for coming. Good morning everybody. I'm Yuri. It's Daniel. We work at Red Hat and We're working in the Kellner real-time team Today, basically we want to spend like 20 minutes Just talking a little bit about sketch deadline Which is well, I still consider it relatively new thing for Linux not really knew it's like been there for at least six years or or something and So but The impression is that maybe not so many people already know about it. Maybe some we have some users not so many so I Guess the first very first question so that the this talk is Mostly about future stuff so stuff that we intend to implement and fix the implement But I guess it really makes sense for for the audience if You actually understand what basically we're talking about so how many of you raise your hands, please know what's getting the lanes Okay, so kind of half of the audience so I guess we can spend yeah a few few minutes maybe actually With a with a little background, but it will be quick like five minutes and then we go Maybe we can go faster on the future stuff I just wanted to put here basically a few reference for for you so that Maybe when you go home and if you are still interested you can go there So I really recommend you to I guess read these two LWN articles Daniel wrote that Last year and they basically provide you both a theory Introduction theoretical introduction and some examples on how you can use this thing and why it might be useful for you and Yeah, I just put here for example. This is one of the possible use cases of this thing which is a real-time scheduler implementation policy for the Linux scheduler and It is supposedly pretty good for all the periodic type of workload that actually needs some kind of quality of service guarantees, let's say I Can potentially be used for strict real-time type of workloads But you can in the soft real-time use case can actually be helpful as well in this case For example, this is pretty simple I guess example wants to tell you that if you have a video processing thing that you have to execute every 16 millisecond because maybe you have a frame rate of let's say six years you can in principle tell the scheduler, okay? I really want you to reserve the 60 millisecond every 16 millisecond every 60 millisecond you want to reserve me five millisecond of time that I can spend Executing my stuff and then after that basically, that's This kind of will make sure that you can execute the thing so yeah, this is basically how can you can use it and Yeah, maybe you can Okay Does it work? Okay, good so Just trying to simplify why do we care about scared that line and why people try to use this this feature let's suppose that we have a system with three tasks that One task runs one unit of time every four the other two units of time every six and The last one three units of time every eight units of time So if we compute the utilization of the system, it will be very close to 100 percent So the system will be very low So if we try to assign the priorities in the best way using the rate monotonic Which is there's a theory that explains that why it's the best way this task set Say, okay, this is my highest part one. This is the second highest and the third This task set is not schedulable within the deadlines using the fix the priority which is the schedule file for the scheduler While if we put this Very low task set on the schedule line in a single CPU we can make it So there is a property of the schedule line that says us that for a single CPU case or for a One single queue for each CPU we can schedule up to 100 percent of time of the tasks While meeting all their deadlines and that's why we try to chase using more and scan that line and that's why Even though it's not as simple as the schedule file we spend some time working on it Okay. Yeah, I guess the other thing is basically the basic idea is that if you If you have like a workflow composed of multiple threads and you want to consolidate those threads in the unless amount of CPUs There might be one way to do it just because it gives you This type of quality of sense you can't is anyway Hopefully that gave you a little bit of introduction and again if you if you want to know more Please reach us after the talk and maybe have a look at the links that I shared in the first lights What we want to actually go through quickly today are the Things that we are working on so What we have in Linux, it's already useful, but it's really the base and there are few things that Needs to be fixed and a few things that we want to introduce to Potentially make this thing more useful for for everybody Okay, let's start with the the first thing so this is about priority narrative So hopefully you're already Aware of this problem. It's a classic real-time system problems when you have multiple tasks with potentially different deadlines that actually work on a shared data and then they use a mutex and Pregnant and solves the problems with the priorities of these these tasks so currently we have a priority maintenance mechanism implemented, which is Deadline and so deadline uses deadline that I mean deadlines to actually schedule tasks so the priority is basically the deadline and The way it works is basically the the task with the the closest so that the highest priority task will Give the deadline the current deadline to the mutex owner when it it blocks on the mutex Unfortunately currently this is Well, let's say that it's lightning correct There are known problem problems and bugs with the actual inheritance thing and the actually the the most worrisome part is that to make it work we We needed to Basically Relax the runtime enforcement property or deadline when the president and is in act Actually, this is the other nice feature of a scared deadline So it's not only that the task has scheduled Consider considering dynamic deadlines so that we can reach a higher Sepulterization but we actually enforce that the task cannot execute for more than He actually requested to the system so the runtime I showed you in the very first slide So that fifth five millisecond is that a mantra that a month of time that ice can actually execute But if you try to execute for more than that, it will be stopped So that will be enforced so that other tasks are not job or dies in their execution and Yeah, so if the task is actually priority boosted this part of the enforcement Doesn't is not actually working anymore So the task can actually execute for more than what requested to the system and of course can be a problem So what we are working on there are already a patch a bit posted as RFC on the you know, Scandinavian at least is what we call private inheritance and Basically the basic idea would be to he narrate the full runtime of a period property of the Task donor so when a higher priority task blocks on the mutex he has any it is a desk a deadline task He already has a runtime of a period Couple and that thing has to be inherited by the task currently holding the mutex so with that we can keep the runtime enforcement enabled and And basically solve the problem in more general way in a more safer way Basically what we let what we want is to Let the mutex owner execute using the scheduling context of The potential several donors next slide should clarify what I mean by scheduling context So this is the a simple example of what might happen on a single CPU you have three tasks There is a very low priority task. So this task is activated at this instant in time And he has an absolute deadline, which is pretty far in the future then it actually shares a resource protected by mutex a With these higher highest priority task desire priorities just because it's Absolute deadline in this instant. Let's say your time is the Closest one. So it's the earliest one What happens is that what we want is that at the moment in time where this highest priority task blocks on mutex a it actually Can so this guy can inherit the properties of the highest priority tasks so that if a medium priority task that doesn't have to doesn't share anything with the other two comes and Starts executing at this moment. It doesn't preempt the lowest priority task. So and so that The highest priority one can actually finish executing in time This is basically what I meant by saying that we want to inherit the scheduling context of the of the highest priority task so the donor we can actually so if you look at the schedule of the task struct you can Potentially divide the information that we have inside there between a scheduling contest and execution context So the scheduling context is basically what you need to actually implement a scheduling policy For example, I'd say for example for RT. It's almost basically Only the the the priority of the task and for deadline We have as I said the runtime and period so the information that the schedule needs to actually know what to do And which task has to still run at every moment in time. So basically with the mechanism will be Inheriting this this information here, but still using the execution context to actually make the task run So for example, if the affinity of this task was On the Considering one CPU the task won't be able to run for example on the affinity of the highest priority task So we just inherited part of the information that there is It is attached to this task over here. It's kind of yeah, I guess if as you can imagine It's kind of tricky to implement. So there will be a little time to make it work right a bit but They're working on it Okay next thing is Yeah, see group support and This is a so current is cadet line has no see group support at all What we want to do. I'll try to go a little faster is to both implement Let's say not hierarchical Group support Which means that the basically the admission control Will be performed will be the user can be performed also Among group of tasks, which he might be useful if you have multiple users on your system currently is really a per task thing and the So it's pretty much using Something like the RT group cad which is already in there for FIFO but the Next thing which is the Probably the most interesting thing will be to be able to have a two-level scheduler. So be able to group Well, this case of FIFO task but can be potentially also CFS task inside deadline reservation And that's nice because then you have the properties of the deadline entities So the fact that they have guarantees guaranteed for your service Implementation but extend those at group or tasks so for example if you have a group of Task example pipeline not tasks that all I have to perform One thing so you have An end to end deadline with this this way will be probably simpler to to actually make use of deadline Just because you don't have to assign different deadlines to each of your over the task that that basically creates your Pipeline by going to say one single thing for the for the whole set Okay, that's so Continuing the same idea of trying to place deadline tasks or trying to place other tasks inside the deadline task We have the real-time problem In such a way to avoid the starvation of no real-time tasks We have a mechanism which is the real-time problem that reserves by default 95 percent of the time For real-time tasks both deadline and schedule leaving a space for the no real-time tasks to run The problem with these the current approach is that if we don't have tasks This system goes idle and many people don't want to have their real-time tasks waiting while the system is idle, right? and So the idea is to bring the deadline scheduler to the root of all these schedulers and generalizing the Context that you just explained like Having a deadline scheduler in the base With one reservation for running deadline and the schedule five-fold tasks and another reservation for the normal tasks While allowing to the other schedulers to reclaim some space Right, so rather than going idle if the normal Normal tasks just run just for a short period. We can reclaim the time for the other schedulers Peter is a fan of these approach and he is suggesting this and he also started doing a pet set that he shared with us and It works fine The only problem is that when we have a deadline scheduler. We are not sure of which task has the The highest priority always Currently in the way that we place the pic next next CPU We have these cad deadline as the highest priority scheduler then schedule five-fold and then schedule normal but when we put them inside a container with cad deadline the Order in which we will execute these schedulers will depend on the deadline of the reservation So if we have a two let's say two deadline tasks With the same period of one one millisecond, which is the default case on Linux if they to start at same time This is a feasible scheduler because both have the same deadline So I can start executing the real-time first and then the normal But we can also have in the normal the normal Scheduler starting to execute before the real-time scheduler and that's not the behavior that everybody wants So this idea is promising it resolves a problem But we need to analyze it better to avoid such problems maybe not using the deadline as a scheduler, but using the Another kind of schedule based in that line, which is the least lacks the first are the ed is a L So the idea is good, but we need to be sure that we will not mess up with the current behavior, right? and Another topic that we might chase in the near future is Improved the schedulability of the mode core behavior of scared deadline This cad deadline it's already the app scheduler They are good for this single CPU case and they are optimal in the single CPU case in such way In the it means that we can execute a hundred percent of time of deadline tasks But when we go for a global scheduler that is One single queue for all the CPUs. We have some anomalies that Involving large tasks, which is very unlikely to to have on a system But still they exist in which the system does not does not schedule as much as possible For example, let's say that we have these tasks with a six unit of time over nine and another six over nine And one four over nine you see here We have a tree units of time available here tree here So we could there is a space to place these four these four units of time to run here But as they have the same deadline doesn't matter the way I put here with global scheduler I cannot schedule them without missing the deadline and This is unknown Let's say not a problem, but a soft problem with global. Let's say So When we start having big tasks the schedulability of the global edf is not that good But we have other ways to schedule the the tasks over the CPUs Which is one way is When we receive a task we have one scheduler per CPU one edf scheduler per CPU and we call this partition When we we will run out of the deadline. I'm sorry When we receive a task rather than having one queue have one queue per CPU and we place that task on a single CPU and let it run There and we call this partition and usually using some risks like best fit and worst fit with partition scheduler we can generally schedule more tasks set than global But there are cases in which the the partition scheduler By itself would not work as well, which is this case like if I try to put place this task here. It would not schedule So there is one theory which is the same partition scheduler That is this the This line is the one that schedules more That works as follows so First I try to place each task on a single CPU and when I don't have more space available I split the the rest of the tasks like shortening the deadline and placing it part of the Of the task in one CPU and the rest of the task on the other CPU and then We have a feasible scheduling and this is the good point about the the same partition and even in the Multi-parquet multiple core cases we can reach a scalability of around 80 or 90 percent of CPU time Which is more than enough for the Linux case Okay much time to be up. It's already question and answer. Okay, so yeah, I'll just skip this and Yeah, I just want to mention before going to questions that we are actually organizing pizza that this year will be the 40 year where we have this little summits like a really a small thing with 50 people was really focused on the scheduler and power Management issues like all this stuff will probably discuss about more than that and please have a look at the side where we have the articles of what happened in the last three years And please come if you are interested in discussing this thing. It's we have several maintainers and really Deep dive and focus. So, yeah, thank you. And if you have questions, they're happy Yeah, I guess it was a kind of tough thing to Yes, if you anyway, please come to us if you are interested in this thing. Okay. Thank you