 So, I'm Claudius Cordino from Evidence. Unfortunately, Yuri is in the process of switching companies, so he asked me to do this presentation. I'm not such a good speaker as Yuri, but I will try to illustrate all the things that are going on, scared the headline and starting from the ones that have been recently merged. So, I've divided this presentation in some phases. In the first stage I will briefly recall how the new algorithm of scared headline works, the one that has been just merged. Then I will illustrate some ongoing features and finally some others that are under discussion and probably also the most important. So, bandwidth reclaiming. The problem was that sometimes a real-time task needs more bandwidth than the one that has been allocated through its reservation. And maybe the system is not fully loaded, so we have some spare bandwidth that we could give to the task. This happens, for example, in some systems, like if we want to handle network traffic or rendering of particularly heavy frames. The solution that has been envisioned is the bandwidth reclaiming. So, hollow task to consume more than allocated, but still under some constraints, like up to a certain maximum fraction of CPU time, because we don't want to experience starvation of low priority tasks. And if this doesn't break, of course, the real-time guarantees of the other real-time tasks. The algorithm that has been merged is called GRUB, which stands for reading reclamation of a new set bandwidth and replaces the constant-banded server, which was the algorithm that was implemented previously. Developed mainly by Squal Santana with the collaboration of Evidence and ARM. And it's already mainline and there is a pretty good documentation already there in case you want to have a look at it. I will try very briefly to give you an idea of how it works. Mainly, a schedule and task can be in three states. The first state is called active contending, which is when the task is ready for execution. It's not blocked. Instead, we have two different states for a blocked task, which are called active noncontending and inactive. The idea is that the task stays inactive noncontending if we cannot reclaim its bandwidth without breaking the real-time guarantees. As soon as we can reclaim its bandwidth, the task enters the inactive state. So this is very trivial. When a task blocks, it enters the active noncontending. After a certain amount of time, there is a timer firing. We call it zero-lag timer. And the task enters the inactive state. We account for the bandwidth of all active tasks in the run queue, which is called running bandwidth in the code. And we also account for the total bandwidth on the run queue, which is called this bandwidth. Let me make a simple example. Suppose task one should execute four milliseconds every eight milliseconds, but after two milliseconds, the task blocks. Then it enters the active noncontending state. After other two milliseconds, the zero-lag timer fires, so the task enters the inactive state and the active bandwidth, which is called the running bandwidth, is lowered. So the task two can execute for more time if it has set the SCAD flag reclaim, which is a flag that allows to specify that the task can reclaim the bandwidth. And finally, we have some spare bandwidth given by the real-time limits to execute lower priority tasks, like SCAD other. This is the formula that we have used in the code. I'm not going to spend much time on this. You can look at it within the documentation anyway. It includes several parameters like the real-time limits and also the utilization, the bandwidth of the whole run queue. So I'm not going to spend too much time on this. Some experimental results taken from the talk by Yuri at ELC. Suppose you have two tasks, the first one with a reservation of six milliseconds every 20 milliseconds, but with a task that consumes just five milliseconds, so you can see that there is some spare bandwidth here. And the task two, which experiences some occasional variances in the execution time. We have plotted the cumulative distribution function, which is the probability that the response time is less or equal to a certain value. And using the original CBS, you see that 25% of times the response times go above the reservation period of the task two. Instead, using rub, you see that the task two always completes before the reservation period because task two is using the bandwidth left by task one. So it's easy to understand that in this sense the task can execute for more time because task one is not using its full reservation time. So this concludes what has been already merged in the mainline kernel because you want to have a look at it. I will start now telling some features that are under development within Schedule Deadline. The first one is the integration with the Schedule Tool. Currently, Schedule Tool, which is the CPU frac governor bunded to the schedule, currently Schedule Tool runs Schedule Deadline tasks at the maximum CPU frequency. Our idea is to extend Schedule Tool such that instead of reclaiming the bandwidth to execute the task for longer time, we reclaim the bandwidth to lower the CPU frequency while still meeting the real time guarantees. The algorithm taken from the literature is called GrubPA, where PA stands for Power Aware. And we already discussed some design choices at the OSPM meeting in April. These have been the choices that we discussed. The first one is to use the active bandwidth rather than the total bandwidth for frequency scaling. This means that we have more aggressive energy efficiency. To use the frequency at the moment of the runtime accounting, even if it's been already changed by other scheduling classes, because other scheduling classes are free to change the frequency, of course. And finally, the most discussed one was to set the key thread to schedule Deadline with a special flag. With a special flag. We sent the latest EarthSC on July. We are ready to submit a new version where we took into account some issues, for example, about priority inheritance, which was broken for a scheduled deadline for the key thread that didn't have bandwidth. It was a special scheduled deadline task, but without bandwidth. So it gave problems with priority inheritance. This has been fixed and will be fixed in the next submission. These are some experiments that we have done. Actually, we meant to present them at the Linux kernel workshop, but at the real time workshop, but it was cancelled. We already had some values and we have run some experiments on four core IMX6, changing the period and changing the reservation values for understanding how it performs versus the current schedule and also versus the performance governor. We have taken the tip three for comparison of the consumption. As you can see in the first column, we have run one single reservation changing the runtime from 10 milliseconds to 100 milliseconds and a period of 100 milliseconds and inside the reservation we have put one scheduled deadline task with a period of 100 milliseconds and 90% of the runtime was 90% of the reservation runtime. As you can see, we have much lower energy consumption than using schedule or performance and also the number of deadlines is experienced by the task is more or less zero, especially when compared with respect to schedule. Then we have run the same experiments this time using 100% of the reservation runtime and of course in this case we have a higher number of deadline misses, but again the number of deadline misses with graph PA is much lower than using schedule and the consumption is still below at least for values of bandwidth lower than 70%. We also have tested the same kind of task using 10 milliseconds period for the reservation and task and finally using one reservation per core with one task in each reservation. These experimental results show that we can lower the frequency still meeting the deadlines and we always get better values than using the schedule the normal schedule Governo. I don't need to eat the thing, right? Almost. So there the blue lines are actually higher than the yellow lines. Bottom row? For values of the bandwidth higher than the bottom. And then one more here. That don't look good. We still have to do further investigation about why for 10 milliseconds I will talk about the 10 milliseconds in the next slide, but yeah we have seen this, but if you compare that's the only case where it performs worse than schedule but if you look at schedule here schedule doesn't perform well even for low values of the bandwidth What we have noticed is that when the granularity of time for the period is of the same order of magnitude of the time to switch the frequency we start experiencing the deadline misses In particular we have run some tests on Odroid XU4 which is a big little system which takes more than 3 milliseconds for doing the frequency switch and if we use 10 milliseconds period we start experimenting a lot of deadline misses So we have thought about how to meet heat So you are saying 3.5 milliseconds for a frequency switch so is the CPU doing nothing in that time and waiting for the frequency to settle or what? It seems that it's doing nothing it's not executing the real time task Oh great. This time is not just hardware it's the whole driver starting the frequency switch and looking at the tables I suppose that most of the time is hardware but there is also a bit of hover by the driver for choosing the frequency But if it's more than a few microseconds then the driver should be rewritten So from what I understand the main problem of switching frequencies on the simple arms is that all the regulator stuff is behind an I squared C bus which means you need scheduling in order to change the frequency but we are driving it from the scheduler Supposedly there are newer parts with a mailbox interface to a firmware so you can actually change or put in requests but the longest time I think is settling of the frequency this chip will run but you are not exactly sure at what rate or at least that's my understanding of it so the CPU does not stall it just takes time to settle on the new voltage or frequency And in this cases there is a very high amount of deadline misses because of course you have a very short deadline and very early deadline and you are losing maybe time to trying to adjust the frequency maybe in these cases it would be more appropriate to remain the same frequency and trying to meet the deadline Anyway, we have tried to mitigate this factor by ignoring the rate limit you know there is this rate limit which prevents too often changes of the frequency scaling so ignoring this rate limit when we have an urgent request from schedule to increase the frequency and also buffering urgent requests arriving when the key thread is in progress because if the key thread is in progress maybe lowering the frequency from a previous request if you arrive in that moment your request will not be handled just when it is finished but it will be handled later on So if I remember Raphael and I don't know who either Morton or something they want to put in a max filter so whilst this thing is in progress or over the rate limit period find the maximum request and program that the moment you go in again Lowering is not that important but you want to raise Anyway, with both these options enabled we still have a too high number of deadline misses I mean if it takes three and a half millis it can affect the thing So the only solution we came out is to start using the total bandwidth rather than the active bandwidth In that case you wouldn't have any frequencies which you wouldn't need but of course you lose in terms of energy efficiency So the first question of my presentation is would be ANOVA in CS file system to select the kind of bandwidth to be used would be a viable solution Should we default to using this bandwidth rather than running bandwidth What do you think? I'm not sure on sys but ANOVA might be ok The default, yeah I don't know Depends on the platform I think because if you've got a non-sucky platform this might all work lots better Just saying If you have other opinions or comments about how to handle this scenario just let me know of course So another feature under development this is mostly by by Scola Santana is the hierarchical or group scheduling I will try to say something and then Tomasa will correct me if I say something wrong The first RFC has been sent on March by Scola Santana on the mailing list and it consisted of three pages quite big actually And the idea is that we have the first level which is scared deadline and then the second level you can have FIFO or for example other scared deadline tasks and so on And the idea is that this could eventually replace real time throttling which is also provided in the same submission an example of usage through the C groups and the behavior is that if we have a task with runtime 10ms and the period 100ms the task is always to execute 10ms on every CPU At the moment it's unclear if we proceed with this if the community prefers a different API or a different behavior or if the community prefers to focus on more urgent features of scared deadlines so the development here is stalled so what do you think Yeah, this has been going on for quite a while the problem is affinities as you know charging every CPU in the system for a group works but is very pessimistic charging the other approach is a minimum concurrency which is good for packing but does not deal with tasks that have arbitrary affinity because then the task affinity is dictated by the deadline scheduler and not by the FIFO task running within and it's not clear to me how we can bridge that or what is actually desired by people who want to use this the per CPU reservation is very pessimistic so I can see people not wanting to use that because it's just too pessimistic but people are too used to using affinities for FIFO tasks to readily use minimal concurrency so yeah, I don't know how to go forward on this to one, keep FIFO behavior and two, build something that is actually a real time system I mean we can fudge it of course but that doesn't make anybody happy I think so yeah I don't know so basically so the answer to your question would be we have arbitrary affinity which is really a big, big stopper for this so a question is what if we can work around this affinity problem I mean is the scenario you have in mind people are used into this affinity is the scenario with single CPU affinities so it's just the need for mixing single CPU affinities with system wide no pin down tasks or does it go more complex that would be useful to know more about can I make my point I think that we already support arbitrary affinities for the FIFO and not supporting it inside the deadline would be a break so we should be able to schedule arbitrary affinities before we can do it possible so let me first answer or try to answer so I think most of the proper real time tasks only use single CPU affinity however since we've allowed it I'm sure there's a whole bunch of software out there that tries to be cute so yeah I really don't know if we can disallow FIFO to use anything other than single people will complain I think it would be awesome to do and the patch would be really simple but the fallout will be massive I'm afraid and then Thomas do you know of any sane real time program that uses arbitrary overlapping affinities that's the wrong question because I do not know about any sane real time programs to begin with no but yeah I mean the problem is I know only a few actual use cases and there the affinities are sane because I told them or teach those people to make them sane affinities and real time priorities and all these kind of things but people do a lot of fancy stuff out there and I mean if you look at the reports which come in on RT users you know what people are doing or trying to do I mean a lot of the a lot of the stuff out there we all know that is just done by oh let's assign some random priority see what breaks and then try again and after a while set of priority settings you don't know why it works but it works genetic programming yeah ok so basically to take I mean one possibility could be to or at least something we we have in mind is to on one hand to try to just you know maintain this for a little wide but just for experimentation purposes so for example we have already a rebase for 13 something I think it was actually tips get maybe tips get just made a few days ago so one thing you could do is to preserve some of the work you did is explicit slack time scheduling for CFS this is something that Bjorn also asked for many years ago and that is something that could be trivially done with much of the infrastructure that you have here right how about just thinking not as a SCAD deadline but about reservations per CPU and inside these reservations we schedule like the CFS and the RT it's not this deadline schedule there would be just a a way to provide fairness but the reservations, think on reservations to substitute the RT profiling and not the profiling but providing bandwidth for CFS inverting the story ok so that could be something useful to prototype but that would be something that would be invasive in the overall scheduling infrastructure so you would end up touching how would that relate with bandwidth controlling CFS then so the idea is as Daniel already said is to replace the RT throttle with an explicit reservation for CFS so you simply schedule CFS to run in your 5% default reservation and then if there isn't anything else to run it will run whatever other deadline task or real-time 5.0 task there are and that way you avoid the starvation issues on CFS that your default while 1.5.0 9.0 task has because the deadline will override that and provide CFS some bandwidth so it's a bandwidth provision it's basically what just a few last words so what we are planning to work on some of these we are already working on so basically ok on one hand together with Daniels and that we are actually looking at this completely semi-partitioning schedule that is a completely different way of dealing with this affinities problem that we have currently in SCAD deadline so in that way we would kill the global EDF part of the SCAD deadline or if it makes any sense we can still recover it it doesn't look like so so that's one line but it's still a prototyping stage another line we have at the moment is to keep going with this bandwidth inheritance problem so tackling better this priority inheritance when you have these reservations so what happens along with use of RT-mutex and how to deal that properly in multi-course and other things we are dealing we are actually we are working on power management but for this heterogeneous platforms like big little and so we plan to have something on that line as well so like some policy or maybe integration to the EAS where scheduling framework by arm or something in that line to deal with SCAD deadline tasks properly over these heterogeneous platforms that looks like quite a pain at the moment and yeah so those are more or less the upcoming things yeah I don't know if you have also some further slides yeah Daniel will maybe then you have something on the semi-partition in the slides just me too yeah I welcome you to present the semi-partition and schedule hey special guest I wasn't ready to present so real time presentation yeah that's a real real time presentation real time decision so the semi-partition scheduler that we were discussing here what is the idea there are some use cases in which we have a schedulable task set in which we place these three tasks to run on two CPUs but near global or partition scheduler are able to schedule these tasks because they have the same deadline here so if I put I cannot place this task here near here or if I put it first I would miss this task deadline there are current cases but they exist so it's not feasible near with global or with partition which are the options that we have now on SCAD deadline so the world have to say about this Bjorn Brandenberg which is a researcher in Germany and Gil they made a paper last year showing that by using semi-partition scheduler they can be almost they can be nearly optimal optimal in the sense that they can schedule whatever task set which is able to find a schedule it is able to find the schedule as well so usually they can schedule 99% of the utilization or the CPU using the semi-partition approach the point of this paper here we cannot just apply this to Linux because they reach this value only if they know on beforehand all the workload that they have to schedule they know on beforehand run a lot of heuristics and then they find how to split task among the processors and make the schedule so it's not a we cannot apply this to Linux because we don't know the workload on beforehand so in one way to provide an online way to do this that is in one way to do this approach but for a task set that you don't know on beforehand this guy is from Italy from the Scola Superiode Santana where I'm studying Tomaso and the Claudio is from too they simplified this approach and created a semi-partition online scheduler based on this work but relax it to be able to do the computation online while running, taking decisions in new tasks that we don't know so how good is this online semi-partition scheduler compared to the this line is the global scheduler and these three lines are heuristics for a partition like I separate each CPU and try to place tasks on that CPU is not migrating and this upline here is the is the work present on this paper so compared to the global global in the worst case it can schedule like a half of the CPU time while if this new approach we can schedule like 94% of the CPU time and comparing to the heuristics for the for the partition here we have a 61% 62% of the CPU time while if the partitioning simple partitioning we can reach like 87% almost 90% of the CPU time which is like it is not optimal we do not reach the 100% but it takes I think it takes 100% of Linux users because Linux user would not place 100% of CPU time in schedule in tasks and we also need to have spare time to run for example the bandwidth inheritance so we need to have some time to spare time there to be used so on our opinion this is pretty close to the optimum for Linux so more or less how does it work how could this algorithm or how does a same partition scheduler could resolve this problem this is just an example simple example first it tries to pin the task to the CPUs and then after pinning when we see a task which it cannot place it changed a little bit the task doing a period transformation a risk which says that how much time do I have here I have 3 units of time so I will put 3 of the 4 units of time here and I will reduce the deadline of this partition of this reservation reducing by the time that is left for 1 unit of time so I reduce this by 1 unit of time and place the rest on the other CPU in which it fits so I make a reservation of this CPU of 1 unit of time with a deadline of 1 and the period will be the same the period is the same so voila we can schedule this task set in this way and this is more or less how it works so we have more heuristics but this is a simplified version question thank you if you schedule it this way then you need to account for the transfer of the data of the task to another CPU if those 2 CPUs are on the hyper threads of the single one then it is not so big problem so basically then it is not big problem but at the moment when you start to move the task you need to put into your heuristic quite complex nonlinear no, the point is that in a comparison of the global scheduling with the same partition schedule in the global scheduler they do way more migrations and under partition scheduler we can have at most M migrations M tasks migrating so we reduce the number of migrations of the tasks actually it is better on the migration then is the question if it is not better to ask the application to basically define which part is least connected to another part that the migration has lowest cost so basically the application should somehow make the system aware that now it is in the area that the migration cost is not so big because you usually compute with some big matrices and then you have some relatively narrow path from one part of the algorithm to another one so it is more complex task here you are assuming applications actually know what the heck they are doing this is false no, the point is that we can even mitigate this with a simple thing from Linux for example on the global scheduler we would have migrations and we cannot ok, Steven has a question sorry? ok, yeah ok, we have more control over migrations and I would say something later but I would say no using these way we can enable arbitrary affinities and so if you want a test to not migrate you just need to set the affinity to one CPU and then you avoid that is one way or we can even add a flag saying please don't migrate ok, he didn't say no it's a good I have a question about the the 119 because that's basically saying the deadline is a 1 I'm surprised why does it have to be 11 because I was looking at this as 1.99 right there because once it migrates over you're saying it immediately has to run but in these cases we are in the heuristics it's known that there is a space for this task here for example we know that if we have just one task here it will have three spare times if it has three spare times I can use one immediately to push at max one unit of time so basically you would need of course a complex test here to be exact, which is called the Dbf demand bound function so that's the test that we would need theoretically to answer exactly whether we can schedule this kind of stuff there ok, this is a very easy example if you pick a little bit more elaborated I mean the test is complex so what we've actually seen with these heuristics results that also Daniel showed earlier this heuristic is a simplified version of the Dbf that doesn't consider the full Dbf test but it considers only the first few points and then it makes a linear approximation of what would be this Dbf function so that's why it's not completely the same but it gives sufficiently good results as shown by this random task sets we've been generating in this it has to be 119, yes 108, no the problem is that if you make it 108 so the first task over there there's no guarantee it will actually be scheduled that way as showed in the picture so in the worst case basically the 389 task may be scheduled just you know it may tend at time 8 that's the it's actual worst case that on the first CPU the task would end at at 8 times a lot so in that case it has to be 11 so that when it migrates it gets scheduled immediately there's a by the way there's a paper explaining all these decisions here show the link for the paper show the link for the paper no the reason why I'm saying that is okay you subtracted the one from it was originally 499 correct so you subtracted one from the deadline so the artificial so you actually took the real deadline and you subtracted one from it to make an artificial deadline for how much you need to put on another CPU now considering we had a full what's it called a perfect migration scheduler so basically had a migration overhead of zero that's just our perfect world ponies ideally then I could still see it still making it because you subtracted it so when it switches over it's got the next deadline I said it would be 199 but nines were coming up right away so it would have to schedule right away then anyway so that's my question is why does it have I don't see the reason why it's got to be 11 here still but I guess I have to read the paper to see a more complex case because this is not a case where that's required okay this is just a simple example but this is a heuristic which is known to be good for partition and they have a paper showing that that's a good heuristics and they were able to reach these 99 percent using this yeah I think that the original paper C equals to D is from Allen Burns isn't yeah it's from Allen Burns so well known researcher so so the same partition scheduler it's still a work in progress I'm working with a professor Tomaso he's my PhD advisor that's why I must have agreed with him always no I'm kidding so it changed how the deadline scheduler deal with multi processors but it's not a new scheduler we are just changing how the schedule deadline works when a a task switch to deadline these heuristics will select where to put the tasks and how to split it if needed one thing is that in the most of the cases there will be no split of tasks and tasks will be pinned to the processors we just need to split when we are reaching a very high overload very high load so in the most of the time tasks are pinned to processors and so we are avoiding migrations at all and yeah just to be fair as the heuristic the placement heuristic sometimes cannot really find room for a new task that is coming later so in that case at the moment we move like just one I think it's in the current heuristic we try to move just one of the already placed tasks so in that case it wouldn't undergo migration it can be still placed in a single CPU but it can be changed later as new tasks are coming so this is a heuristic so of course there is plenty of work of space to improve it reason about to see what is best really for Linux or for specific use cases but so there was just to clarify that once you are pinned down on a CPU maybe you could have to move later to make room for others so it's still there but the good point is that such decisions for migrations aren't to take place for example in the pool way they are in the runtime it's just when you accept a new task with the this is called so we reduce the complexity of the runtime scheduler the runtime on this deadline we currently have entities in this case we still have the entity but we will not schedule the entity we will schedule reservations like this is one reservation and this is another reservation so one task can have one or more reservations and we schedule the reservations not the entity so the benefits are our t problems are reduced to single core there are two parts of the real time theory we have the single core which is from 60s and they are very stable everything runs in a simpler way and we have optimal solutions or we have the mood core which is known to be harder we have some anomalies we have some cases which we know it's not possible to be optimal at all so we reduce all the problems to single core which is very good from the theoretical standing point the risk is set only when we switch the priority or when we switch the priority of the tasks or when we have hot plugs so we have a lease run time overhead and the overhead is more on these operations which are known to not be not to be real time we are expecting to have latencies here it's not a problem to have latencies here so there is no need to pull tasks we just push tasks and this reduces a lot of the time which we held the RQ lock which is good mainly a remote lock so we can reduce the latencies for RT tasks for example running on the other lock if you have to migrate and OK, tasks are mostly opinion to CPU Rfinits come for free because we can just change the heuristics which is simple and this is a real problem we have tried to resolve this as in the global scheduler there is one paper mentioned this very complex to understand and the current status we are seeing the theoretical results in the reality which is good it's not always like this but still in our work in progress we are working on a paper about it and the points to be discussed are in this case we need to run the admission control in the kernel nothing delegating it to user space we could delegate it to user space but then we would have to change the API and I think and I say to Tomaso, if you want to change the API I will send the patch from Tomaso Kuchinota for me, I don't want to hear about changing API and OK this is a change and currently we don't have the admission we currently don't have the like we have an admission control it provides not deadline but bounded lateness tardness and so we will have to do this but well actually that's a that's a change in the way that we do but it's to avoid changing the API and well the current deadline does not consider implicit deadline tasks but the current scheduler it was like a relaxed way to accept the tasks but actually there are cases in which we missed the deadline so we don't consider still don't consider implicit deadlines but the current scheduler doesn't consider that in a like it formally like papers like to do so we are having we are facing the same problem and that's admission control that makes things very nasty if you want to so pushing the outer user space gets you a whole bunch of problems because then there might be multiple clients or multiple different clients or it's a mess so first let's see how horrible the internal admission control is before we start considering other things but as is the admission control yes it is simple but it does provide the bounded tardiness even for implicit it just doesn't provide no deadline misses on UPI I think in this case it's not bounded right so how horrible so how horrible is it just to give you an example you first place a task without any affinity constraint you place it somewhere then later it comes another task with an affinity constraint so it doesn't keep the former one to a different one so it's not just admission control just to clarify this is like relocating stuff around and of course if you want to make it exact it's going to take time and be complex and when we change affinities and when we hotplug operations these must be done in kernel and we're not talking no, no, no we're not in the seconds range we could be in the milliseconds range too at the moment depends on the load on the schedule and I load on the system which is maybe expected to be low so no problem one thing could be that if you change another tasks affinity sorry affinity but I mean the temporary this internal temporary the CPU where it's placed when it's not running so maybe you could either you force migration while it's running and you're doing now or you wait for it to be get go to sleep and that takes time so the scenario that would care I suppose is this adaptive stuff that you guys have been doing if it's good enough for that I assume it's good enough because the adaptive stuff wants to very frequently readjust parameters but it returns to the implicit deadline tasks even though we don't have a result for implicit deadline tasks now we know that it's impossible for example to be optimal on online implicit deadline tasks but that turns easier when you use a single core theory and we base on single core so trying to fix this in the global you can keep it I would just mention other features that have been discussed in the past one of those was the reclaiming by the motion which was mentioned last year at the real time summit and requested probably by the android group we have a patch available on top of group scheduling so I have no idea if this is a patch which is still needed or it has been superseded by the fact that grab algorithm can reclaim so I don't know if Peter wants to have something about this Peter do you think it's still important to have a reclaiming by the motion or grab as superseded this need so yeah it's something that is fairly frequently requested and it shouldn't be too hard to do I think I don't know show me a patch horrible it is the signal thing is also something that people have asked for should not be hard I think the initial patches it's a few lines we just killed it because it wasn't absolutely necessary for the initial thing so we stripped everything out but if people want it we can certainly look at doing it ok good so on one of your very first slides I had this question that might go to this in your initial example of what grab was you had two tasks and task A ran for a little bit went to sleep task B was running and it went into it's overtime and kept running if task A in the dotted line dotted space he's over budget you're giving him extra time if task A wakes up at that point does he get control does he get informed about the fact that he has lost so task 1 now becomes unblocked task 2 is in sort of overtime state when task 1 get control here when task 1 resumes and he's in active in active state it gets a new a new period of time the run time and the period start from that moment so it will not have the deadline here it's recompted so it will be at for example task 1 starts at 5 then it enters the active contending state and the new deadline will be 5 plus 8 so 13 so that's how the algorithm works so it will be it will have a deadline which is more or less here similar to what CBS did that's the one thing is the deadline isn't true like earlier deadline first because of the constant span with scheduler the constant span of scheduler modifies the deadlines and periods by the percentage when it wakes up and that's where I believe the zero lag is once you hit the zero lag that means that it wakes up at this point it's going to be reset to whatever earlier deadline first and there's been bugs that Daniels didn't discover and kind of like whack-a-mo fixing because of that so other features that are under discussion and that might be the most important and I've left to the end so that Peter can see a word later on and privilege the usage so the possibility of using deadline without the root privilege and finally the proxy execution or bandwidth inheritance stuff we had the first prototype of bandwidth inheritance made by Yuri long time ago and we have put it on revised it on newer kernel but we didn't have time for proper debugging and so on and Peter has some new code and the group in PISA Scholasentan and Evidence are willing to collaborate on testing development and so on so concluding schedule integration is we think is almost ready for mainline we will do a new submission in the next weeks and we have solved the problem with the priority inheritance that we had and we would like to figure out how to deal with short periods on some on some platforms and we would like among all the features that have been discussed we would like to have a list of priorities of the most requested features so we don't waste time on things that nobody care so like I said earlier I'm not an RT users because I'm not actually a user I don't use this stuff I just work on it I run Linux but I don't do much of that line stuff or real time stuff other than I mean my editor is not a real time process and that's basically all I run the thing that I see requests for is the unprivileged use because then more user space can start using it than the media players can start using it Android can more easily use it or expose it to the apps and all the other stuff so I think that is one of the more important parts to get working that of course includes improving the bandwidth issue yeah the various CBS fallback modes sending a signal or doing if people want to sure do a patch I don't particularly care I mean if the patch is ugly I'll care other than that not so much can you go back one or two slides there was some point that I wanted single CPU affinity we end up at EZDL or something like that the thing I dreamt up in Dubrovnik that is with a simpler admission control with some to be so I presume because I don't know that if people set single CPU affinity they expect no deadline misses because this is what they know from EDF and for that to work in combination with the global stuff you need a different scheduling policy which is where the EZDL where you make at least laxity and EDF are used to both the dual parameter space to prioritize between the local hard real time and the global slightly softer real time tasks which will be iffy I know we talked about this so if if it all falls out of the semi partition ok, if we do it without the semi partition it's going to be icky I mean we can do it probably it's going to be more work so the EZDL thing where you make the least laxity in the earliest because there is two parameters in the space we can use that to differentiate you were in Dubrovnik, right? so you've seen that it turns out that you have two schedulers in one we're running late I think Thomas wants me to hurry up but yeah my opinion is that we will turn one scheduler into two schedulers no no, it's just the one it's a bit icky I can talk to you Mike?