Re: sched: SCHED_DEADLINE v6

[Ove Karlsen]

On Mon, 05 Nov 2012 21:23:41 +0100, Martin <marogge@xxxxxxxxxxxxx> wrote:

> On 11/04/2012 09:00 PM, Uwaysi Bin Kareem wrote:
> > Nobody knows? This is really obscure for an EDF patch. Making things a
> > bit more accessible should be a priority. I think a lot of enthusiasts
> > would like to have smooth control over stuff, without windows-jitter. If
> > you can do a robot arm, jitter-free with this, then I am very  
> > interested.
> >
> > uwaysi@Millennium:~/Kildekode/sched_deadline-schedtool-dl$ ./schedtool  
> > -E
> > -t 500:1000 3718
> > ERROR: could not set PID 3718 to E: SCHED_DEADLINE - Function not
> > implemented
> > uwaysi@Millennium:~/Kildekode/sched_deadline-schedtool-dl$
> >
> > On Sun, 04 Nov 2012 20:02:25 +0100, Uwaysi Bin Kareem
> > <uwaysi.bin.kareem@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > > How does the modified schedtool work? There is no updated  
> > > documentation.
> > >
> > > http://gitorious.org/sched_deadline/schedtool-dl/commits/latest/2.6.36-dl-V3
> > >
> > >
> > > If anyone could give an example of a 1000uS period / 500uS time, with
> > > schedtool, or any other relevant information.
> > > Most examples online use parameters that are no longer supported.
> > >
> > > Peace Be With You.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"  
> > in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
>
> Hi,
>
> I assume the reason nobody answers is that the cpu scheduler is an  
> emotional subject.
>
> However, if you really want a smooth desktop and a deadline scheduler  
> (albeit it might not be as configurable as you seem to want it to be),  
> try BFS or the whole CK patch.
>
> http://ck-hack.blogspot.com/
>
> I have implemented it on a laptop this weekend, and I was surprised by  
> the change in user experience yet again. Mostly during 3D game play.  
> Generally the difference is felt more strongly on low end machines and  
> taxing workloads.
>
> Since you are talking about robot arms: note that BFS is not a real time  
> solution, but is designed around the physiological conditions of the  
> human perception system (where, I believe, 6 ms is equivalent to real  
> time). Maybe a similar deadline approach is useful for robot arms, no  
> idea.
>
> cu Martin

If you ever saw a robot-arm jitter, you`d think of it as faulty. And that  
is how people should think of their PC aswell.

Just the interrupts, preemption (points), daemons, hopefully cleverly  
arranged, to reduce jitter, is what I want.
I did already try BFS. PS: 90hz timer, is very good with BFS also, but the  
jitter-extremes are higher. Meaning large jitters last longer, while small  
jitters, seems smaller. For overall computing CFS actually has less jitter.

What would be really interesting would be to try a scheduler that tries to  
bound latencies, and have accurate timing.

There seems to be generally 3 different profiles people tuned for: Server,  
Mobile, Desktop.
Server guiless stationary, Mobile for minimal power desktop, Desktop, for  
workstation/home low-jitter high-performance.

Maybe these profiles even can be combined a bit, having several hz  
counters, and several scheduling policies.

Peace Be With You.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/