Messages in this thread | | | Date | Wed, 13 Apr 2016 11:08:39 +0100 | From | Juri Lelli <> | Subject | Re: [PATCH RFC v0 00/12] Cyclic Scheduler Against RTC |
| |
On 13/04/16 02:37, Bill Huey (hui) wrote: > [Trying to resend this so that linux-kernel mailer doesn't reject it. > ok just found plain text mode. Will cull the CC list in future > responses] > > Hi Juri, > > It's not for replacing deadline first of all. I'm not fully aware of the > kind of things being done with deadline and I would like links so that I > have some kind of reference >
OK. You can find references in Documentation, in my first reply and embedded in the ELC slides as well. Please, let me know if you need more :-).
> The original motivation for doing this was for a number of reasons: > > 1) Current FIFO/RR policies aren't exact enough for a lot of the mixed > modern multimedia scenarios I saw working a real-world load on an Android > like system. Insufficient feedback to interactive UX tasks that include > things like jackd and pulse audio for low latency applications (music, > keyboard controllers, touch events...) across a span of tasks across the > system. > > Deadline seems to be more localized to a specific application's need and > seems to be hard to use but I'm inexperienced with it. The problems would > benefit from a simpler solution. >
I'm not sure what you mean by "localized", but I believe DEADLINE should be used more widely to service the same kind of applications you are referring to. It's still a quite new addition to the scheduler, so it is understandable that we still have some legacy to fight. But we can get better in the future.
> 2) The need for a scheduler to be driven by an external interrupt from a > number sources directly. >
If you use DEADLINE to service the activity an interrupt source might trigger, I think you can already do this.
> 3) The need for a global view of the system so that power management > decisions can be made sensibly made in multicore systems. It's not a > scheduler alone but ideal would have more influence over power management > decision on battery powered devices, etc... >
That's true. But it is also already something we currently are working on. I don't know if you are following the schedfreq/schedutil threads [1], for example, but there we are discussing how to integrate scheduler and cpufreq more closely. And you might also be interested in the EAS effort [2].
> 4) other reasons that should be in the docs but I got sick of writing > exhaustive documentation on the matter... >
:-)
> That's the best I can do for now. I need to post new version with > compilations fixes. There's a lot of problems with code regarding > portability and other issues with the initial revision. >
OK. Feel free to ask if you also decide to experiment with DEADLINE and find any problem with it.
Best,
- Juri
[1] https://lkml.org/lkml/2016/3/17/420 https://lkml.org/lkml/2016/2/22/1037 [2] https://lkml.org/lkml/2015/7/7/754
| |